Re: optimizing vacuum truncation scans

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: optimizing vacuum truncation scans
Дата
Msg-id CANP8+jLAFNVnUZRG463qvffWS1o6Uge6Gj5yWk5vVqb4hbPjWQ@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>)
Список pgsql-hackers
On 22 July 2015 at 17:11, Jeff Janes <jeff.janes@gmail.com> wrote:
On Wed, Jul 22, 2015 at 6:59 AM, Robert Haas <robertmhaas@gmail.com> wrote:
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. 

I wouldn't say forever, as it would be easy to revert the change if something more important came along that conflicted with it. 

I think what is being said here is that someone is already using this technique, or if not, then we actively want to encourage them to do so as an extension or as a submission to core.

In that case, I think the rely-on-VM technique sinks again, sorry Jim, Jeff. Probably needs code comments added.

That does still leave the prefetch technique, so all is not lost.

Can we see a patch with just prefetch, probably with a simple choice of stride? Thanks.
 
--
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dean Rasheed
Дата:
Сообщение: Re: A little RLS oversight?
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: A little RLS oversight?