Re: Disabling Heap-Only Tuples
От | Robert Haas |
---|---|
Тема | Re: Disabling Heap-Only Tuples |
Дата | |
Msg-id | CA+TgmoYTbHTOxWZhup7MAYA6rfBbASw2Pu-cW+K0JmCpSVog8g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Disabling Heap-Only Tuples (Matthias van de Meent <boekewurm+postgres@gmail.com>) |
Ответы |
Re: Disabling Heap-Only Tuples
|
Список | 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 по дате отправления: