Re: Block level concurrency during recovery

Поиск
Список
Период
Сортировка
От Teodor Sigaev
Тема Re: Block level concurrency during recovery
Дата
Msg-id 48FCADF2.8010609@sigaev.ru
обсуждение исходный текст
Ответ на Re: Block level concurrency during recovery  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Block level concurrency during recovery  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
> I don't understand why in ginVacuumPostingTreeLeaves() we lock only the
> root page for Cleanup and no others. Why do we need to hold Cleanup lock
> on the root? If the index is concurrent safe for existing scans, why is
> it not safe for new scans also? And the converse: if it is not safe for
> new scans, why is it safe for existing scans? 

Because we wish to prevent concurrent inserts and page deletion just to simplify 
code. LockForCleanup guarantees that insertion process is not work here (it 
keeps root buffer pinned all time of insertion). New scan processes can't start 
as a side effect.

Note, in most cases it keeps enough concurrence because all that is about work 
on one tree in GIN index. Usually, there is a lot of such trees in index - for 
each lexeme if we speak about tsearch index. So, there is a place for 
improvements but I don't believe that will give a big advantage for performance 
in typical usage of GIN.

-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
  WWW: http://www.sigaev.ru/
 


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

Предыдущее
От: Teodor Sigaev
Дата:
Сообщение: Re: Index use during Hot Standby
Следующее
От: Tom Lane
Дата:
Сообщение: Re: SQL:2008 LIMIT/OFFSET