Re: Reducing relation locking overhead

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Reducing relation locking overhead
Дата
Msg-id 419.1133627383@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Reducing relation locking overhead  (Greg Stark <gsstark@mit.edu>)
Список pgsql-hackers
Greg Stark <gsstark@mit.edu> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> What's worse, once you have excluded writes you have to rescan the entire
>> table to be sure you haven't missed anything.

> I was thinking you would set a flag to disable use of the FSM for
> inserts/updates while the reindex was running. So you would know where
> to find the new tuples, at the end of the table after the last tuple
> you read.

There are paths that do not consult the FSM, eg update where the new
tuple fits on the same page as the old, or where the backend has already
been given a target page by the FSM.  And this "set a flag" idea in
itself has enormous costs, because the flag will become a central point
of contention: it *must* be touched by every single tuple insertion.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Esha Palta
Дата:
Сообщение: unsubscribe
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Reducing relation locking overhead