Re: the big picture for index-only scans - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: the big picture for index-only scans
Date
Msg-id 4E4F39DB.6070604@enterprisedb.com
Whole thread Raw
In response to Re: the big picture for index-only scans  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: the big picture for index-only scans
List pgsql-hackers
On 19.08.2011 23:02, Robert Haas wrote:
> On Fri, Aug 19, 2011 at 2:51 PM, Gokulakannan Somasundaram
> <gokul007@gmail.com>  wrote:
>> won't it make the 99
>> sessions wait for that visibility map while holding the exclusive lock on
>> the 99 heap pages?
>
> Hmm, you have a point.  If 100 backends simultaneously write to 100
> different pages, and all of those pages are all-visible, then it's
> possible that they could end up fighting over the buffer content lock
> on the visibility map page.  But why would you expect that to matter?
> In a heavily updated table, the proportion of visibility map bits that
> are set figures to be quite low, since they're only set during VACUUM.
>   To have 100 backends simultaneously pick different pages to write
> each of which is all-visible seems really unlucky.   Even if it does
> happen from time to time, I suspect the effects would be largely
> masked by WALInsertLock contention.  The visibility map content lock
> is only taken very briefly, whereas the operations protected by
> WALInsertLock are much more complex.

The above could already happen in 8.4, where the visibility map was 
introduced. The contention on the VM buffer would be just as bad whether 
you hold the heap page lock at the same time or not. I have not heard 
any complaints of contention on VM buffers.

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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: two index bitmap scan of a big table & hash_seq_search
Next
From: Heikki Linnakangas
Date:
Subject: Re: the big picture for index-only scans