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

From Alvaro Herrera
Subject Re: Minimum tuple threshold to decide last pass of VACUUM
Date
Msg-id 20150803155241.GH2441@postgresql.org
Whole thread Raw
In response to Re: Minimum tuple threshold to decide last pass of VACUUM  (Simon Riggs <simon@2ndQuadrant.com>)
Responses 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  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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.  Otherwise, index tuples become
lingering pointers (and when such heap address are later refilled, they
become corrupted indexscans).

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.  That would make such
vacuums go much quicker.  (More accurately, if the updating xid is older
than the freeze point, then remove the tuple, but otherwise keep it.)

My point is that emergency vacuums are troublesome for various reasons
and it would be better if they did only the minimum possible.

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



pgsql-hackers by date:

Previous
From: Anastasia Lubennikova
Date:
Subject: Re: [PATCH] Microvacuum for gist.
Next
From: Geoff Winkless
Date:
Subject: ON CONFLICT DO UPDATE using EXCLUDED.column gives an error about mismatched types