From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
Cc: | Gurjeet Singh <gurjeet(at)singh(dot)im>, Postgres Hackers <pgsql-hackers(at)postgresql(dot)org>, Will Storey <will(at)summercat(dot)com> |
Subject: | Re: Disabling vacuum truncate for autovacuum |
Date: | 2025-01-27 20:38:39 |
Message-ID: | CA+TgmoZMXN19eorKdeiiFCv3AJFVaUAfkzRuamnt8A9U8uJSqg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On Mon, Jan 27, 2025 at 4:55 AM Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> wrote:
> My suggestion for the parameter name is "autovacuum_disable_truncate".
Then it would have a different name than the reloption, and the
opposite sense. In most cases, we've been able to keep those matching
-- autovacuum vs. autovacuum_enabled being, I believe, the only
current mismatch.
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.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Shaheed Haque | 2025-01-27 20:41:08 | Content of pg_publication using a local connection versus network connection? |
Previous Message | Jim Vanns | 2025-01-27 18:08:53 | Parallel workers via functions? |
From | Date | Subject | |
---|---|---|---|
Next Message | Melanie Plageman | 2025-01-27 21:21:53 | Re: Eagerly scan all-visible pages to amortize aggressive vacuum |
Previous Message | Nathan Bossart | 2025-01-27 20:30:17 | Re: speedup COPY TO for partitioned table. |