On Mon, Aug 28, 2023 at 11:50 AM Matthias van de Meent <boekewurm+postg...@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
