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 по дате отправления: