Re: Freeze avoidance of very large table.
От | Masahiko Sawada |
---|---|
Тема | Re: Freeze avoidance of very large table. |
Дата | |
Msg-id | CAD21AoDv1pV=yPNukrTWEOZ=COPSMwsJNCOXuu9MQAL0kgR4Gw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Freeze avoidance of very large table. (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: Freeze avoidance of very large table.
|
Список | pgsql-hackers |
On Thu, Aug 20, 2015 at 11:46 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > Jim Nasby wrote: > >> I think things like pageinspect are very different; I really can't see any >> use for those beyond debugging (and debugging by an expert at that). > > I don't think that necessarily means it must continue to be in contrib. > Quite the contrary, I think it is a tool critical enough that it should > not be relegated to be a second-class citizen as it is now (let's face > it, being in contrib *is* second-class citizenship). > Attached patch is latest patch. The how to do the VM regression test is changed so that we do test without diagnostic functions. In current patch, we do VACUUM and VACUUM FREEZE table, and check its value of pg_class.relallvisible and relallfrozen. When doing first VACUUM in regression test, the table doesn't have VM. So VACUUM scans all pages and update exactly information about the number of all-visible bit. And when doing second VACUUM FREEZE, VACUUM FREEZE also scans all pages because every page is not marked as all-frozen. So VACUUM FREEZE can update exactly information about the number of all-frozen bit. In previous patch, we checked a bit of VM one by one using by diagnostic function, and compared between these result and pg_class.relallvisible(/frozen). So the essential check process is same as previous patch. We can ensure correctness by using such procedure. Regards, -- Masahiko Sawada
Вложения
В списке pgsql-hackers по дате отправления: