Re: Minimum tuple threshold to decide last pass of VACUUM - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Minimum tuple threshold to decide last pass of VACUUM
Date
Msg-id CANP8+jLaRUqG+oz7qosBo5odAYVpQxegWtbYnkj8w6V_p3iVdA@mail.gmail.com
Whole thread Raw
In response to Re: Minimum tuple threshold to decide last pass of VACUUM  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses 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>)
List 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 by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: nodes/*funcs.c inconsistencies
Next
From: Kevin Grittner
Date:
Subject: BRIN trivial tweaks