Re: New GUC autovacuum_max_threshold ?

Поиск
Список
Период
Сортировка
От Frédéric Yhuel
Тема Re: New GUC autovacuum_max_threshold ?
Дата
Msg-id 1dafbd92-1c3d-469d-91f6-a0a2e47e4c08@dalibo.com
обсуждение исходный текст
Ответ на Re: New GUC autovacuum_max_threshold ?  (Nathan Bossart <nathandbossart@gmail.com>)
Ответы Re: New GUC autovacuum_max_threshold ?
Список pgsql-hackers
Hi Nathan, thanks for your review.

Le 24/04/2024 à 21:57, Nathan Bossart a écrit :
> Yeah, I'm having trouble following the proposed mechanics for this new GUC,
> and it's difficult to understand how users would choose a value.  If we
> just want to cap the number of tuples required before autovacuum takes
> action, perhaps we could simplify it to something like
> 
>     vacthresh = (float4) vac_base_thresh + vac_scale_factor * reltuples;
>     vacthresh = Min(vacthres, vac_max_thresh);
> 
> This would effectively cause autovacuum_vacuum_scale_factor to be
> overridden for large tables where the scale factor would otherwise cause
> the calculated threshold to be extremely high.


This would indeed work, and the parameter would be easier to define in 
the user documentation. I prefer a continuous function... but that is 
personal taste. It seems to me that autovacuum tuning is quite hard 
anyway, and that it wouldn't be that much difficult with this kind of 
asymptotic limit parameter.

But I think the most important thing is to avoid per-table configuration 
for most of the users, or event autovacuum tuning at all, so either of 
these two formulas would do.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Experiments with Postgres and SSL
Следующее
От: Anthonin Bonnefoy
Дата:
Сообщение: Re: Fix parallel vacuum buffer usage reporting