Re: vacuum_truncate configuration parameter and isset_offset

On Mon, Mar 24, 2025 at 10:27 AM Nikolay Shaplov <dhyan(at)nataraj(dot)su> wrote:

> В письме от понедельник, 24 марта 2025 г. 20:09:23 MSK пользователь Nathan
> Bossart написал:
>
> > > You've just changed the whole engine, for what is seems to be an
> > > exceptional case, that can be solved via existing means.
> > I have not changed the whole engine. I have added an optional integer
> > field to a single struct.
>
> That potentially changes the behaviour of all boolean options. They will
> never
> be what they were before.
>

The implementation sure looks like a pure opt-in from this angle. Can you
provide a concrete behavior change example of a boolean option that hasn't
opted-in to help me see what I'm missing. I do agree that this should have
been a separate commit but let us at least try and do some analysis before
throwing the whole thing away. A refactoring/change like this would need
an example to work with anyway so that thread you want to create is this
one in practice. It has a poor subject line for the material, true, but
that doesn't seem uncommon around here...

My main concern when first seeing this was adding an integer to every
single option in the entire system for something that is going to be zero
99.9% of the time. A bit bloated but not directly impacting behavior. I
wanted to avoid that by just looking in pg_class.reloptions for the
vacuum_truncate setting when needed. I'd rather do that then turn this
into an enum that is masquerading as a boolean.

David J.