Re: Documentation fixes for pg_visibility
От | Robert Haas |
---|---|
Тема | Re: Documentation fixes for pg_visibility |
Дата | |
Msg-id | CA+TgmoY0SsPvPUWVPc1p1_yn1QDktmdTK7KJwbsNxTDtoyhTrA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Documentation fixes for pg_visibility (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: Documentation fixes for pg_visibility
|
Список | pgsql-hackers |
On Mon, Jun 27, 2016 at 5:56 PM, Michael Paquier <michael.paquier@gmail.com> wrote: >> Under what circumstances would you wish to check only one page of a relation? > > What I'd like to be able to do is to stop scanning the relation once > one defective tuple has been found: if there is at least one problem, > the whole vm needs to be rebuilt anyway. So this function could be > wrapped in a plpgsql function for example. It is more flexible than > directly modifying this function so as it stops at the first problem > stopped. I think most likely the best way to handle this is teach VACUUM to do PageClearAllVisible() and visibilitymap_clear() on any page where VM_ALL_FROZEN(onerel, blkno, &vmbuffer) && !all_frozen. This would go well with the existing code to clear incorrectly-set visibility map bits, and it would allow VACUUM (DISABLE_PAGE_SKIPPING) to serve the purpose you're talking about here, but more efficiently. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: