Horton

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

Pavel Stehule <pavel.stehule@gmail.com>

View thread
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Michael Paquier <michael@paquier.xyz>, Amit Kapila <amit.kapila16@gmail.com>, Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>, Fujii Masao <masao.fujii@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2018-04-19T20:06:45Z
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.

2018-04-19 21:56 GMT+02:00 Alvaro Herrera <alvherre@alvh.no-ip.org>:

> Michael Paquier wrote:
>
> > Then, let's consider the beginning of the first commit fest of v12 as
> > judgement.  Implementing radix tree for shared buffers is a long-term
> > project, which has no guarantee to get merged, while a visibly-simple
> > reloptions which helps in some cases...
>
> In the scenario we studied, the truncations were causing periodic
> hiccups which were quite severe.  The truncations were completely
> useless anyway because the table grew back to the original size daily (a
> few dozen GBs I think).  That was a lot of unnecessary work, and under
> exclusive lock no less.
>

has sense

Pavel

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