Re: Minimum tuple threshold to decide last pass of VACUUM

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Minimum tuple threshold to decide last pass of VACUUM
Дата
Msg-id CANP8+jLaRUqG+oz7qosBo5odAYVpQxegWtbYnkj8w6V_p3iVdA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Minimum tuple threshold to decide last pass of VACUUM  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Minimum tuple threshold to decide last pass of VACUUM  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Re: Minimum tuple threshold to decide last pass of VACUUM  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers
On 3 August 2015 at 17:36, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Simon Riggs wrote:
>> * For emergency anti-wraparound VACUUMs we shouldn't scan indexes at all,
>> since they aren't critical path activities at that point

> It is not possible to skip scanning indexes completely, unless no tuples
> are to be removed from the heap.

Right.

> But actually this is an interesting point and I don't think we do this:
> if in emergency mode, maybe we shouldn't try to remove any dead tuples
> at all, and instead only freeze very old tuples.

+1 ... not sure if that's what Simon had in mind exactly, but it seems
like a correct statement of what he was getting at.

Yes, that's what I was thinking, I just didn't say actually it. I'd been thinking about having VACUUM do just Phase 1 for some time, since its so much faster to do that. Will code.

--
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: nodes/*funcs.c inconsistencies
Следующее
От: Kevin Grittner
Дата:
Сообщение: BRIN trivial tweaks