On Tue, May 10, 2011 at 11:34 AM, Jesper Krogh <jesper@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
