Re: reloption to prevent VACUUM from truncating empty pages at theend of relation - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: reloption to prevent VACUUM from truncating empty pages at theend of relation
Date
Msg-id 20180419005818.GE957@paquier.xyz
Whole thread Raw
In response to Re: reloption to prevent VACUUM from truncating empty pages at theend of relation  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: reloption to prevent VACUUM from truncating empty pages at theend of relation
List pgsql-hackers
On Wed, Apr 18, 2018 at 07:41:44PM +0530, Amit Kapila wrote:
> I think it makes sense to pursue that approach, but it might be worth
> considering some alternative till we have it.  I remember last time
> (in 2015) we have discussed some another solution [1] to this problem
> (or similar) and we have left it unattended in the hope that we will
> get a better solution, but we are still in the same situation.  I
> think in general it is better to go with the approach which can fix
> the root cause of the problem, but if that is going to take a long
> time, it is not terrible to provide some workable solution which can
> help users.

Yeah, I can understand that feeling.  When we talked about the
compression of FPWs back in 9.5, we discussed that if we had
double-writes then this would not be necessary, and we are still with
wal_compression but without double writes (actually, it happens that
compression of pages can also be used with double writes, but that's
enough highjacking for this thread..).

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

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Adding an LWLockHeldByMe()-like function that reports if anybuffer content lock is held
Next
From: Peter Geoghegan
Date:
Subject: Re: Adding an LWLockHeldByMe()-like function that reports if anybuffer content lock is held