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
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 |