Re: Minimum tuple threshold to decide last pass of VACUUM

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Minimum tuple threshold to decide last pass of VACUUM
Date: 2015-08-04 05:28:56
Message-ID: CAB7nPqRJYvh=fr3Mfi_SgjMVJKxLcMP=aVDV0ZKbEmmTNPBD2g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 4, 2015 at 2:04 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On 3 August 2015 at 17:36, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
>> Alvaro Herrera <alvherre(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Janes 2015-08-04 05:41:53 Re: Re: Using quicksort and a merge step to significantly improve on tuplesort's single run "external sort"
Previous Message Michael Paquier 2015-08-04 05:21:16 Re: pg_rewind tap test unstable