Pavan Deolasee wrote:
> On Thu, Dec 11, 2008 at 7:15 PM, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.com> wrote:
> Do we have any tests to prove that the VM page lock does not indeed
> become a bottleneck ?
No.
> I can do some if we don't have already.
Oh, yes please!
>> Only the first update to a page needs to clear the bit in the visibility
>> map, so I don't think it'll become a bottleneck in practice. Frequently
>> updated pages will never have the bit set in the visibility map to begin
>> with.
>
> Well that's true only if you reject my heap-prune patch :-) Otherwise,
> heap-prune will again set the bit (and I believe that's the right
> thing to do)
I'm not sure if we should set the bits in very aggressively. If we're
more aggressive about setting the bits, it also means that we have to
clear the bits more often, increasing the likelihood of contention that
you were worried about. Also, skipping a few pages here and there in
vacuum doesn't make it any faster in practice, because you're reading
sequentially. You need long contiguous regions of pages that can be
skipped until you see a benefit.
Setting the PD_ALL_VISIBLE flag on the heap page itself more
aggressively might be more interesting, because of the small seqscan
optimization.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com