Re: Block level concurrency during recovery - Mailing list pgsql-hackers

From Teodor Sigaev
Subject Re: Block level concurrency during recovery
Date
Msg-id 48FCADF2.8010609@sigaev.ru
Whole thread Raw
In response to Re: Block level concurrency during recovery  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Block level concurrency during recovery
List 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 by date:

Previous
From: Teodor Sigaev
Date:
Subject: Re: Index use during Hot Standby
Next
From: Tom Lane
Date:
Subject: Re: SQL:2008 LIMIT/OFFSET