MIME-Version: 1.0
References: <E1tvHdt-0009Bj-1j@gemulon.postgresql.org>
 <993142.1742484654@sss.pgh.pa.us>
 <CAApHDvo9E+imdCrOjhx00unxxDYox=7fr2+ATfyEw86iRwy3AA@mail.gmail.com>
In-Reply-To: 
 <CAApHDvo9E+imdCrOjhx00unxxDYox=7fr2+ATfyEw86iRwy3AA@mail.gmail.com>
From: "David G. Johnston" <david.g.johnston@gmail.com>
Date: Fri, 21 Mar 2025 09:39:26 -0700
Message-ID: 
 <CAKFQuwaK2vT19DTcPHoa6HUvmqbfA5HnRdxXKcuGHM211YNAAA@mail.gmail.com>
Subject: Re: pgsql: Add vacuum_truncate configuration parameter.
To: David Rowley <dgrowleyml@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Nathan Bossart <nathan@postgresql.org>,
	pgsql-committers@lists.postgresql.org
Content-Type: multipart/alternative; boundary="000000000000fc69350630dce70b"
Archived-At: 
 <https://www.postgresql.org/message-id/CAKFQuwaK2vT19DTcPHoa6HUvmqbfA5HnRdxXKcuGHM211YNAAA%40mail.gmail.com>
Precedence: bulk

--000000000000fc69350630dce70b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 20, 2025 at 4:07=E2=80=AFPM David Rowley <dgrowleyml@gmail.com>=
 wrote:

> On Fri, 21 Mar 2025 at 04:30, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >
> > Nathan Bossart <nathan@postgresql.org> writes:
> > > Since there's presently no way to determine whether a Boolean
> > > storage parameter is explicitly set or has just picked up the
> > > default value, this commit also introduces an isset_offset member
> > > to relopt_parse_elt.
> >
> > Uh, what?  Why is it a good idea to distinguish those states?
> > Seems like that risks some very surprising behavior, ie if the
> > default is "true", why shouldn't that act exactly like an
> > explicit setting of "true"?
>
> I was thinking about this yesterday as the topic of a
> user-configurable options for truncation threshold came up in [1]. I
> find it a bit annoying the boolean vacuum_truncate reloption was added
> (a few years ago) as we could have instead added a more flexible
> truncate_scale_factor that could be set to -1 to disable truncation.
> Maybe it's too late now as reloptions are not easy to remove. Adding
> this GUC now does put us a bit further down the path of the boolean
> option.


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,
and probably should be prohibited.

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 level
is valid and reasonably solved.  The "default" behavior hasn't changed but
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.

David J.

--000000000000fc69350630dce70b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif"><span style=3D"font-family:Arial,Helve=
tica,sans-serif">On Thu, Mar 20, 2025 at 4:07=E2=80=AFPM David Rowley &lt;<=
a href=3D"mailto:dgrowleyml@gmail.com">dgrowleyml@gmail.com</a>&gt; wrote:<=
/span></div></div><div class=3D"gmail_quote gmail_quote_container"><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex">On Fri, 21 Mar 2025 at 04:30, Tom=
 Lane &lt;<a href=3D"mailto:tgl@sss.pgh.pa.us" target=3D"_blank">tgl@sss.pg=
h.pa.us</a>&gt; wrote:<br>
&gt;<br>
&gt; Nathan Bossart &lt;<a href=3D"mailto:nathan@postgresql.org" target=3D"=
_blank">nathan@postgresql.org</a>&gt; writes:<br>
&gt; &gt; Since there&#39;s presently no way to determine whether a Boolean=
<br>
&gt; &gt; storage parameter is explicitly set or has just picked up the<br>
&gt; &gt; default value, this commit also introduces an isset_offset member=
<br>
&gt; &gt; to relopt_parse_elt.<br>
&gt;<br>
&gt; Uh, what?=C2=A0 Why is it a good idea to distinguish those states?<br>
&gt; Seems like that risks some very surprising behavior, ie if the<br>
&gt; default is &quot;true&quot;, why shouldn&#39;t that act exactly like a=
n<br>
&gt; explicit setting of &quot;true&quot;?<br>
<br>
I was thinking about this yesterday as the topic of a<br>
user-configurable options for truncation threshold came up in [1]. I<br>
find it a bit annoying the boolean vacuum_truncate reloption was added<br>
(a few years ago) as we could have instead added a more flexible<br>
truncate_scale_factor that could be set to -1 to disable truncation.<br>
Maybe it&#39;s too late now as reloptions are not easy to remove. Adding<br=
>
this GUC now does put us a bit further down the path of the boolean<br>
option.</blockquote><div><br></div><div class=3D"gmail_default" style=3D"fo=
nt-family:arial,helvetica,sans-serif">Not seeing much point in trying to ge=
t rid of the on/off switch.=C2=A0 It just won&#39;t make sense to choose a =
tunable value of zero to disable something, and probably should be prohibit=
ed.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,=
sans-serif"><br></div><div class=3D"gmail_default" style=3D"font-family:ari=
al,helvetica,sans-serif">I&#39;m seeing an implementation detail discussion=
 here, not a behavior one.=C2=A0 The field complaint that we don&#39;t let =
the=C2=A0DBA control this at the GUC level is valid and reasonably solved.=
=C2=A0 The &quot;default&quot; behavior hasn&#39;t changed but now instead =
of hard-coding the default we moved it to a GUC.=C2=A0 The storage paramete=
r is no longer documented as having a default, which is correct.=C2=A0 It n=
ow behaves like most of the other storage parameters in that if unset a GUC=
 provides the value.</div><div class=3D"gmail_default" style=3D"font-family=
:arial,helvetica,sans-serif"><br></div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif">David J.</div></div></div>

--000000000000fc69350630dce70b--