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

From Heikki Linnakangas
Subject Re: Block level concurrency during recovery
Date
Msg-id 4900A49C.1060602@enterprisedb.com
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
Simon Riggs wrote:
> It would also be possible to introduce a special tweak there which is
> that if the block is not in cache, don't read it in at all. If its not
> in cache we know that nobody has a pin on it, so don't need to read it
> in just to say "got the lock". That icing for later.

Heh, that's clever :-). We could actually use a method like that to 
solve the whole problem. After the (replay of the) b-tree vacuum is 
finished, scan through all shared buffers, and get a vacuum lock on 
every page of that index that's in cache. Groveling through all shared 
buffers would be slower for small indexes, though.

I believe the "vacuum lock every leaf page" behavior is only needed for 
system catalogs. You have other issues with those still, namely that 
table locks are not yet taken appropriately, so I'm not sure if this is 
worth worrying about until that's done.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Regression in IN( field, field, field ) performance
Next
From: Andrew Sullivan
Date:
Subject: Re: Unicode escapes in literals