MIME-Version: 1.0
References: <E1tvHdt-0009Bj-1j@gemulon.postgresql.org>
 <993142.1742484654@sss.pgh.pa.us>
In-Reply-To: <993142.1742484654@sss.pgh.pa.us>
From: David Rowley <dgrowleyml@gmail.com>
Date: Fri, 21 Mar 2025 12:07:00 +1300
Message-ID: 
 <CAApHDvo9E+imdCrOjhx00unxxDYox=7fr2+ATfyEw86iRwy3AA@mail.gmail.com>
Subject: Re: pgsql: Add vacuum_truncate configuration parameter.
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Nathan Bossart <nathan@postgresql.org>,
 pgsql-committers@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
 <https://www.postgresql.org/message-id/CAApHDvo9E%2BimdCrOjhx00unxxDYox%3D7fr2%2BATfyEw86iRwy3AA%40mail.gmail.com>
Precedence: bulk

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.