From: Nathan Bossart <nathandbossart@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: Gurjeet Singh <gurjeet@singh.im>
Cc: Postgres Hackers <pgsql-hackers@postgresql.org>
Cc: Will Storey <will@summercat.com>
Subject: Re: Disabling vacuum truncate for autovacuum
Date: Thu, 27 Feb 2025 21:35:51 -0600
Message-ID: <Z8EvFyf1D1AMxjOg@nathan> (raw)
In-Reply-To: <Z7Tl2d7HrG1AQEOc@nathan>
References: <Z2DE4lDX4tHqNGZt@dev.null>
<fa83a77bbca5da4d4864a49c8a27df323f23d28b.camel@cybertec.at>
<CABwTF4U3xkF=ZRi2pztUDxohoN8h6XL10=QmTtuTXoMjzu5-zg@mail.gmail.com>
<f82fc7fbb69a8c8000ad74ced50381257fe57838.camel@cybertec.at>
<CA+TgmoZMXN19eorKdeiiFCv3AJFVaUAfkzRuamnt8A9U8uJSqg@mail.gmail.com>
<Z7Tl2d7HrG1AQEOc@nathan>
On Tue, Feb 18, 2025 at 01:56:09PM -0600, Nathan Bossart wrote:
> On Mon, Jan 27, 2025 at 03:38:39PM -0500, Robert Haas wrote:
>> Also, how sure are we that turning this off globally is a solid idea?
>> Off-hand, it doesn't sound that bad: there are probably situations in
>> which autovacuum never truncates anything anyway just because the tail
>> blocks of the relations always contain at least 1 tuple. But we should
>> be careful not to add a setting that is far more likely to get people
>> into trouble than to get them out of it. It would be good to hear what
>> other people think about the risk vs. reward tradeoff in this case.
>
> My first reaction is that a global setting is probably fine most of the
> time. I'm sure it's possible to get into bad situations if you try hard
> enough, but that's not a unique characteristic. There are probably many
> situations where the truncation is wasted effort because we'll just end up
> extending the relation shortly afterwards, anyway. In any case, it's
> already possible to achieve $SUBJECT with a trivial script that sets
> storage parameters on all tables, so IMHO it would be silly to withhold a
> global setting that does the same thing just on principle.
I spent some time on this one today. A couple of notes:
* Since the reloption is a Boolean, there isn't a good way to tell whether
it is actually set for the table or if it just inherited the default
value. This is important to know because we want the reloption to
override the GUC. I considered a bunch of different ways to handle this,
but everything felt like a cowboy hack. The cleanest cowboy hack I could
come up with is an optional offset field in relopt_parse_elt that points
to a variable that stores whether the option was explicitly set.
* I didn't see a good GUC category for vacuum_truncate. I suppose we could
create a new one, but for now I've just stashed it into the autovacuum
one. Bikeshedding welcome.
Thoughts?
--
nathan
Attachments:
v2-0001-Add-vacuum_truncate-GUC.patch (text/plain, 0B) download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-general@postgresql.org
Cc: nathandbossart@gmail.com, robertmhaas@gmail.com, laurenz.albe@cybertec.at, gurjeet@singh.im, pgsql-hackers@postgresql.org, will@summercat.com
Subject: Re: Disabling vacuum truncate for autovacuum
In-Reply-To: <Z8EvFyf1D1AMxjOg@nathan>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox