Horton

Re: New vacuum option to do only freezing

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: Peter Geoghegan <pg@bowt.ie>, Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>, 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-25T15:10:49Z
Lists: pgsql-hackers 
On Tue, Apr 23, 2019 at 7:09 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> For the second issue, I've changed lazy vacuum so that it reports both
> the number of kilobytes we freed and the number of kilobytes can be
> freed after index cleanup.

I am not very convinced that this reporting is in any useful to users.
Despite N kilobytes of tuples having been freed, the pages themselves
are still allocated and the actual ability to reuse that space may be
dependent on lots of factors that the user can't control like the
sizes of newly-inserted tuples and the degree to which the free space
map is accurate.

I feel like we're drifting off into inventing new kinds of reporting
here instead of focusing on fixing the reported defects of the
already-committed patch, but perhaps I am taking too narrow a view of
the situation.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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