Re: Documentation fixes for pg_visibility

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Documentation fixes for pg_visibility
Дата
Msg-id CAB7nPqRdMbJ2f+H+Ed=mb4ev5BiGFg6DnWQ1F8hdwbMOit+5EA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Documentation fixes for pg_visibility  (Robert Haas <robertmhaas@gmail.com>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Header and comments describing routines in incorrect shape in visibilitymap.c
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Forthcoming SQL standards about JSON and Multi-Dimensional Arrays (FYI)