Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
От | Robert Haas |
---|---|
Тема | Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations |
Дата | |
Msg-id | CA+TgmoY=xMM4hT9MJezDffXSLanbz7gzvpcqvq5_+F-HmFPhzw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
|
Список | pgsql-hackers |
On Wed, Mar 23, 2022 at 4:49 PM Peter Geoghegan <pg@bowt.ie> wrote: > On Wed, Mar 23, 2022 at 1:41 PM Robert Haas <robertmhaas@gmail.com> wrote: > > It seems to me that if DISABLE_PAGE_SKIPPING doesn't completely > > disable skipping pages, we have a problem. > > It depends on how you define skipping. DISABLE_PAGE_SKIPPING was > created at a time when a broader definition of skipping made a lot > more sense. > > > The option isn't named CARE_ABOUT_VISIBILITY_MAP. It's named > > DISABLE_PAGE_SKIPPING. > > VACUUM(DISABLE_PAGE_SKIPPING, VERBOSE) will still consistently show > that 100% of all of the pages from rel_pages are scanned. A page that > is "skipped" by lazy_scan_noprune isn't pruned, and won't have any of > its tuples frozen. But every other aspect of processing the page > happens in just the same way as it would in the cleanup > lock/lazy_scan_prune path. I see what you mean about it depending on how you define "skipping". But I think that DISABLE_PAGE_SKIPPING is intended as a sort of emergency safeguard when you really, really don't want to leave anything out. And therefore I favor defining it to mean that we don't skip any work at all. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: