Horton

Re: reloption to prevent VACUUM from truncating empty pages at the end of relation

Peter Geoghegan <pg@bowt.ie>

View thread
From: Peter Geoghegan <pg@bowt.ie>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Fujii Masao <masao.fujii@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2018-04-17T18:13:57Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add TRUNCATE parameter to VACUUM.

  2. Add vacuum_truncate reloption.

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

On Tue, Apr 17, 2018 at 11:09 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> So rather than a klugy solution that only fixes
> VACUUM (and not very well, requiring user intervention and an unpleasant
> tradeoff), we ought to look at ways to avoid needing a whole-pool scan to
> find the pages belonging to one relation.  In the past we've been able to
> skate by without a decent solution for that because shared buffers were
> customarily not all that big.  But if we're going to start considering
> huge buffer pools to be a case we want to have good performance for,
> that's got to change.

Andres mentioned that he has prototyped an approach to buffer
management that uses a Radix tree, which is generally assumed to be
the right long-term fix.

-- 
Peter Geoghegan