From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
Cc: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Thom Brown <thom(at)linux(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Disabling Heap-Only Tuples |
Date: | 2023-08-28 15:57:03 |
Message-ID: | CA+TgmoYTbHTOxWZhup7MAYA6rfBbASw2Pu-cW+K0JmCpSVog8g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Aug 28, 2023 at 11:50 AM Matthias van de Meent
<boekewurm+postgres(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jesper Pedersen | 2023-08-28 16:11:09 | Re: Commitfest manager for September |
Previous Message | Jeff Janes | 2023-08-28 15:55:52 | Re: Use FD_CLOEXEC on ListenSockets (was Re: Refactoring backend fork+exec code) |