Re: Disabling Heap-Only Tuples - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Disabling Heap-Only Tuples
Date
Msg-id CA+TgmoYTbHTOxWZhup7MAYA6rfBbASw2Pu-cW+K0JmCpSVog8g@mail.gmail.com
Whole thread Raw
In response to Re: Disabling Heap-Only Tuples  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
Responses Re: Disabling Heap-Only Tuples
List pgsql-hackers
On Mon, Aug 28, 2023 at 11:50 AM Matthias van de Meent
<boekewurm+postgres@gmail.com> wrote:
> Agreed on all points. But isn't that true for most most tools on bloat
> prevention and/or detection? E.g. fillfactor, autovacuum_*, ...

Not nearly to the same extent, IMHO. A lot of those parameters can be
left alone forever and you lose nothing. That's not so here.

> I'd prefer that too, but by lack of other work in this area this seems
> like it fills a niche that would otherwise require extremely expensive
> locking over a long time for CLUSTER, superuser+pg_repack, or manual
> scripts that update tuples until they're located on a different page
> (begin; update tuple WHERE ctid > '(12,0)' returning ctid; ...;
> commit;). I agree this is very minimal and can definitely be used as a
> footgun, but with the description that it can be a footgun I don't
> think it's (much) worse than the current situation - a user should
> only reach for this once they've realized they actually have an issue.

Well, I sort of expected that counter-argument, but I'm not sure that I buy it.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: Re: Use FD_CLOEXEC on ListenSockets (was Re: Refactoring backend fork+exec code)
Next
From: Jesper Pedersen
Date:
Subject: Re: Commitfest manager for September