Re: optimizing vacuum truncation scans
От | Robert Haas |
---|---|
Тема | Re: optimizing vacuum truncation scans |
Дата | |
Msg-id | CA+Tgmob=B2pdPt2dunD+SY0HzaCFWCxfEvzW3aBGK+Vr+9uc+Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: optimizing vacuum truncation scans (Jeff Janes <jeff.janes@gmail.com>) |
Ответы |
Re: optimizing vacuum truncation scans
Re: optimizing vacuum truncation scans |
Список | pgsql-hackers |
On Mon, Jun 29, 2015 at 1:54 AM, Jeff Janes <jeff.janes@gmail.com> wrote: > Attached is a patch that implements the vm scan for truncation. It > introduces a variable to hold the last blkno which was skipped during the > forward portion. Any blocks after both this blkno and after the last > inspected nonempty page (which the code is already tracking) must have been > observed to be empty by the current vacuum. Any other process rendering the > page nonempty are required to clear the vm bit, and no other process can set > the bit again during the vacuum's lifetime. So if the bit is still set, the > page is still empty without needing to inspect it. Urgh. So if we do this, that forever precludes having HOT pruning set the all-visible bit. At the least we'd better document that carefully so that nobody breaks it later. But I wonder if there isn't some better approach, because I would certainly rather that we didn't foreclose the possibility of doing something like that in the future. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: