From: | Frédéric Yhuel <frederic(dot)yhuel(at)dalibo(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | New GUC autovacuum_max_threshold ? |
Date: | 2024-04-24 12:08:00 |
Message-ID: | 956435f8-3b2f-47a6-8756-8c54ded61802@dalibo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello,
I would like to suggest a new parameter, autovacuum_max_threshold, which
would set an upper limit on the number of tuples to delete/update/insert
prior to vacuum/analyze.
A good default might be 500000.
The idea would be to replace the following calculation :
vacthresh = (float4) vac_base_thresh + vac_scale_factor * reltuples;
with this one :
vacthresh = (float4) vac_base_thresh + vac_scale_factor * reltuples / (1
+ vac_scale_factor * reltuples / autovacuum_max_threshold)
(and the same for the others, vacinsthresh and anlthresh).
The attached graph plots vacthresh against pgclass.reltuples, with
default settings :
autovacuum_vacuum_threshold = 50
autovacuum_vacuum_scale_factor = 0.2
and
autovacuum_max_threshold = 500000 (the suggested default)
Thus, for small tables, vacthresh is only slightly smaller than 0.2 *
pgclass.reltuples, but it grows towards 500000 when reltuples → ∞
The idea is to reduce the need for autovacuum tuning.
The attached (draft) patch further illustrates the idea.
My guess is that a similar proposal has already been submitted... and
rejected 🙂 If so, I'm very sorry for the useless noise.
Best regards,
Frédéric
Attachment | Content-Type | Size |
---|---|---|
0001-Add-new-GUC-autovacuum_max_threshold.patch.draft | text/plain | 5.4 KB |
image/png | 43.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-04-24 12:27:13 | Re: Why does pgindent's README say to download typedefs.list from the buildfarm? |
Previous Message | Alexander Lakhin | 2024-04-24 12:00:00 | Re: Avoid orphaned objects dependencies, take 3 |