Horton

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

Michael Paquier <michael@paquier.xyz>

View thread
From: Michael Paquier <michael@paquier.xyz>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Fujii Masao <masao.fujii@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2018-04-18T01:00:59Z
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 12:12:26PM -0700, Andres Freund wrote:
> On 2018-04-17 15:09:18 -0400, Tom Lane wrote:
>> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
>>> Andres was working on a radix tree structure to fix this problem, but
>>> that seems to be abandoned now, and it seems a major undertaking.
> 
> I hope to re-ignite work on that later in the v12 cycle. But
> realistically that means it's not going to be mergable for v12.

Need a push of man-hours for that?

>>> While I agree that the proposed solution is a wart, it seems much
>>> better than no solution at all.  Can we consider Fujii's proposal as
>>> a temporary measure until we fix shared buffers?  I'm +1 on it
>>> myself.
>> 
>> Once we've introduced a user-visible reloption it's going to be
>> practically impossible to get rid of it, so I'm -1.
> 
> It's not much work to maintain though? And even the brief AEL lock can
> cause troubles, leaving the scan aside. So I'm like +0.1 or such.

I would say that if the radix tree patch can make it for the first
commit fest and has reviews, then there would be likely no need for this
reloption.
--
Michael