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

From Michael Paquier
Subject Re: Minimum tuple threshold to decide last pass of VACUUM
Date
Msg-id CAB7nPqRJYvh=fr3Mfi_SgjMVJKxLcMP=aVDV0ZKbEmmTNPBD2g@mail.gmail.com
Whole thread Raw
In response to Re: Minimum tuple threshold to decide last pass of VACUUM  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On Tue, Aug 4, 2015 at 2:04 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> 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.

Interesting. I'll be happy to have a look at any patch produced,
that's surely something we want to improve in emergency mode.
-- 
Michael



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: pg_rewind tap test unstable
Next
From: Jeff Janes
Date:
Subject: Re: Re: Using quicksort and a merge step to significantly improve on tuplesort's single run "external sort"