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

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: Michael Paquier <michael@paquier.xyz>
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:13:31Z
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 April 17, 2018 6:00:59 PM PDT, Michael Paquier <michael@paquier.xyz> wrote:
>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?

Not sure what you mean?


>>>> 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.

There's no way it can.


Andres
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.