MIME-Version: 1.0
References: <E1tvHdt-0009Bj-1j@gemulon.postgresql.org>
 <993142.1742484654@sss.pgh.pa.us>
 <CAApHDvo9E+imdCrOjhx00unxxDYox=7fr2+ATfyEw86iRwy3AA@mail.gmail.com>
 <CAKFQuwaK2vT19DTcPHoa6HUvmqbfA5HnRdxXKcuGHM211YNAAA@mail.gmail.com>
In-Reply-To: 
 <CAKFQuwaK2vT19DTcPHoa6HUvmqbfA5HnRdxXKcuGHM211YNAAA@mail.gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
Date: Mon, 24 Mar 2025 11:22:43 +1300
Message-ID: 
 <CAApHDvoGP9kRZNOq7QbqD2ierrCGubQ37oDM8xkgX2zbBou7HA@mail.gmail.com>
Subject: Re: pgsql: Add vacuum_truncate configuration parameter.
To: "David G. Johnston" <david.g.johnston@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Nathan Bossart <nathan@postgresql.org>,
	pgsql-committers@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAApHDvoGP9kRZNOq7QbqD2ierrCGubQ37oDM8xkgX2zbBou7HA%40mail.gmail.com>
Precedence: bulk

On Sat, 22 Mar 2025 at 05:40, David G. Johnston
<david.g.johnston@gmail.com> wrote:
> Not seeing much point in trying to get rid of the on/off switch.  It just=
 won't make sense to choose a tunable value of zero to disable something, a=
nd probably should be prohibited.

Can you explain what does not make sense about it?  We have plenty of
GUCs and reloptions where -1 means "inherit the setting from somewhere
else". Do those also not make sense, or is this one somehow different?

> I'm seeing an implementation detail discussion here, not a behavior one. =
 The field complaint that we don't let the DBA control this at the GUC leve=
l is valid and reasonably solved.  The "default" behavior hasn't changed bu=
t now instead of hard-coding the default we moved it to a GUC.  The storage=
 parameter is no longer documented as having a default, which is correct.  =
It now behaves like most of the other storage parameters in that if unset a=
 GUC provides the value.

The reason I was pointing this out is that I wanted to ensure that
this was considered before we release code with the new GUC. It's true
removing a GUC isn't as hard as removing a reloption and we already
have the reloption. If everyone thinks we'll likely not need
user-tunable options to specify the number of pages required before
truncation occurs then that's fine.  The problem I see is that we
already have lots of GUCs and it'd be nice not to have semi-redundant
ones in the future because we've failed to consider something.  I was
just pointing out the "something" part that we might want to consider.

David