On Tue, May 10, 2011 at 11:34 AM, Jesper Krogh <jes...@krogh.cc> wrote: > On 2011-05-10 14:48, Robert Haas wrote: >> >> We could avoid all of this complexity - and the possibility of pinning >> the visibility map page needlessly - by locking the heap buffer first >> and then pinning the visibility map page if the heap page is >> all-visible. However, that would involve holding the lock on the heap >> buffer across a possible disk I/O to bring the visibility map page >> into memory, which is something the existing code tries pretty hard to >> avoid. > > Assuming that the visibillity map would be used for visibillity testing, > just picking the lock would effectively mean "we want it in the buffers", > which would not be that bad? > > Or what is the downside for keeping it across IO? Will it block other > processes trying to read it?
Heikki might be in a better position to comment on that than I am, since he wrote the existing code. But I think that's basically the issue. When one process has an exclusive buffer lock, nobody else can scan the tuples in that block - so a sequential scan, for example, that reached that block, or an index scan that needed to probe into it, would pile up behind the read of the visibility map page. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
