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  (Jeff Janes <jeff.janes@gmail.com>)
Re: optimizing vacuum truncation scans  (Simon Riggs <simon@2ndQuadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Teodor Sigaev
Дата:
Сообщение: stringify MAKE_SQLSTATE()
Следующее
От: Tom Lane
Дата:
Сообщение: Re: stringify MAKE_SQLSTATE()