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
|
Список | 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 по дате отправления: