Horton

Re: New vacuum option to do only freezing

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, Robert Haas <robertmhaas@gmail.com>, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>, "Bossart, Nathan" <bossartn@amazon.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-04-17T17:46:17Z
Lists: pgsql-hackers 
Masahiko Sawada <sawada.mshk@gmail.com> writes:
> On Wed, Apr 17, 2019 at 5:00 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> I'm thinking that we really need to upgrade vacuum's reporting totals
>>> so that it accounts in some more-honest way for pre-existing dead
>>> line pointers.  The patch as it stands has made the reporting even more
>>> confusing, rather than less so.

> Or, how about reporting the vacuumed tuples and line pointers we
> separately? It might be too detailed but since with this patch we
> delete either only tuples or only line pointers, it's more accurate.

Yeah, if we wanted to expose these complications more directly, we
could think about adding or changing the main counters.  I was wondering
about whether we should have it report "x bytes and y line pointers
freed", rather than counting tuples per se.

			regards, tom lane

Commits

  1. Add toast-level reloption for vacuum_index_cleanup

  2. heap_prepare_freeze_tuple: Simplify coding

  3. Fix missing word.

  4. Allow VACUUM to be run with index cleanup disabled.

  5. Don't mark pages all-visible spuriously