From: | "Imseih (AWS), Sami" <simseih(at)amazon(dot)com> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | David Rowley <dgrowleyml(at)gmail(dot)com>, Joe Conway <mail(at)joeconway(dot)com>, Michael Banck <mbanck(at)gmx(dot)net>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Frédéric Yhuel <frederic(dot)yhuel(at)dalibo(dot)com>, "Melanie Plageman" <melanieplageman(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: New GUC autovacuum_max_threshold ? |
Date: | 2024-05-08 17:30:44 |
Message-ID: | 0A799687-DE0A-4BFC-8900-E1D57EB6C211@amazon.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> This is about how I feel, too. In any case, I +1'd a higher default
> because I think we need to be pretty conservative with these changes, at
> least until we have a better prioritization strategy. While folks may opt
> to set this value super low, I think that's more likely to lead to some
> interesting secondary effects. If the default is high, hopefully these
> secondary effects will be minimized or avoided.
There is also an alternative of making this GUC -1 by default, which
means it has not effect and any value larger will be used in the threshold
calculation of autovacuunm. A user will have to be careful not to set it too low,
but that is going to be a concern either way.
This idea maybe worth considering as it does not change the default
behavior of the autovac threshold calculation, and if a user has cases in
which they have many tables with a few billion tuples that they wish to
see autovacuumed more often, they now have a GUC to make
that possible and potentially avoid per-table threshold configuration.
Also, I think coming up with a good default will be challenging,
and perhaps this idea is a good middle ground.
Regards,
Sami
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2024-05-08 18:00:10 | Re: Add SPLIT PARTITION/MERGE PARTITIONS commands |
Previous Message | Jonathan S. Katz | 2024-05-08 16:17:13 | Re: 2024-05-09 release announcement draft |