Re: Documentation fixes for pg_visibility - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Documentation fixes for pg_visibility
Date
Msg-id CAB7nPqRdMbJ2f+H+Ed=mb4ev5BiGFg6DnWQ1F8hdwbMOit+5EA@mail.gmail.com
Whole thread Raw
In response to Re: Documentation fixes for pg_visibility  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert wrote:
>  I think there should probably be a test for
> all_visible_according_to_vm at the beginning of that so that we don't
> add more visibility map checks for pages where we already know the VM
> bit can't possibly be set.

Yes, that looks like a good idea after more screening of this code.

On Wed, Jul 6, 2016 at 12:21 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> So I'm a bit confused about what you are saying here.  If the page is
> marked all-frozen but actually isn't all-frozen, then we should clear
> the all-frozen bit in the VM.  The easiest way to do that is to clear
> both bits in the VM plus the page-level bit, as done here, because we
> don't presently have a way of clearing just one of the visibility map
> bits.

Yes, that's my understanding as well for what is necessary: clear both
bits in the vm as well as the bit on the page itself, and mark it as
dirty. Way to go.

> Now, since the heap_lock_tuple issue requires us to introduce a new
> method to clear all-visible without clearing all-frozen, we could
> possibly use that here too, once we have it.

For 10.0, working on lower-level routine optimizations of this kind
sounds good to me. But I vote against this level of code reordering in
9.6 post-beta2 if that's what you suggest.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Header and comments describing routines in incorrect shape in visibilitymap.c
Next
From: Peter Eisentraut
Date:
Subject: Re: Forthcoming SQL standards about JSON and Multi-Dimensional Arrays (FYI)