From: | "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> |
---|---|
To: | "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | "Zdenek Kotala" <Zdenek(dot)Kotala(at)sun(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: visibility maps |
Date: | 2008-12-11 13:50:57 |
Message-ID: | 2e78013d0812110550n27a99c42g62dbac5d4a96f6bb@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Dec 11, 2008 at 7:15 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>
>
> Yeah, if we accept that bits can be bogusly set. There is scenarios where
> that can happen already, but they involve crashing, not during normal
> operation and clean shut down. In the future, I'd like to move in the
> direction of making the visibility map *more* reliable, not less, ultimately
> allowing index-only-scans, so I'd rather not start relaxing that.
>
Do we have any tests to prove that the VM page lock does not indeed
become a bottleneck ? I can do some if we don't have already.
> 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)
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-12-11 14:24:38 | Re: visibility maps |
Previous Message | Pavel Stehule | 2008-12-11 13:50:10 | Re: COCOMO & Indians |