Re: New GUC autovacuum_max_threshold ?
От | Nathan Bossart |
---|---|
Тема | Re: New GUC autovacuum_max_threshold ? |
Дата | |
Msg-id | Zy5N-M2jPIYzPdku@nathan обсуждение исходный текст |
Ответ на | Re: New GUC autovacuum_max_threshold ? (wenhui qiu <qiuwenhuifx@gmail.com>) |
Список | pgsql-hackers |
On Wed, Nov 06, 2024 at 08:51:07PM +0800, wenhui qiu wrote: >> Thank you. FWIW, I would prefer a sub-linear growth, so maybe something >> like this > >> vacthresh = Min(vac_base_thresh + vac_scale_factor * reltuples, >> vac_base_thresh + vac_scale_factor * pow(reltuples, 0.7) * 100); > >> This would give : > >> * 386M (instead of 5.1 billion currently) for a 25.6 billion tuples > table ; >> * 77M for a 2.56 billion tuples table (Robert's example) ; >> * 15M (instead of 51M currently) for a 256M tuples table ; >> * 3M (instead of 5M currently) for a 25.6M tuples table. >> The other advantage is that you don't need another GUC. > Argee ,We just need to change the calculation formula,But I prefer this > formula because it calculates a smoother value. > > vacthresh = (float4) fmin(vac_base_thresh + vac_scale_factor * > reltuples,vac_base_thresh > + vac_scale_factor * log2(reltuples) * 10000); > or > vacthresh = (float4) fmin(vac_base_thresh + (vac_scale_factor * reltuples) > , sqrt(1000.0 * reltuples)); I apologize for the curt response, but I don't understand how we could decide which of these three complicated formulas to use, let alone how we could expect users to reason about the behavior. -- nathan
В списке pgsql-hackers по дате отправления: