Pavan Deolasee wrote:
On Thu, Dec 11, 2008 at 7:15 PM, Heikki Linnakangas
<[EMAIL PROTECTED]> 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
