Re: Should we increase the default vacuum_cost_limit?

Поиск
Список
Период
Сортировка
От Julien Rouhaud
Тема Re: Should we increase the default vacuum_cost_limit?
Дата
Msg-id CAOBaU_Z8k1RAB8u761qg-L9EKZzywwiJde=hiuBRN6hvE8+7vQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Should we increase the default vacuum_cost_limit?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Should we increase the default vacuum_cost_limit?
Re: Should we increase the default vacuum_cost_limit?
Список pgsql-hackers
On Sat, Mar 9, 2019 at 10:04 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> I tried this, and it seems to work pretty well.  The first of the two
> attached patches just teaches guc.c to support units for float values,
> incidentally allowing "us" as an input unit for time-based GUCs.

Why not allowing third party extensions to declare a GUC stored in us?
 We need a backward-compatible format for vacuum setting, but I don't
see a good reason to force external extensions to do the same, and it
wouldn't require much extra work.

> The second converts [autovacuum_]cost_delay to float GUCs, and changes
> the default value for autovacuum_cost_delay from 20ms to 2ms.
> We'd want to revert the previous patch that changed the default value
> of vacuum_cost_limit, else this means a 100x not 10x change in the
> default autovac speed ... but I've not included that in this patch.

Otherwise everything looks good to me.  BTW the patches didn't apply
cleanly with git-apply, but patch -p1 didn't complain.

> 2. It's always bugged me that we don't allow fractional unit
> specifications, say "0.1GB", even for GUCs that are integers underneath.
> That would be a simple additional change on top of this, but I didn't
> do it here.

It annoyed me multiple times, so +1 for making that happen.


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

Предыдущее
От: Dean Rasheed
Дата:
Сообщение: Re: [HACKERS] PATCH: multivariate histograms and MCV lists
Следующее
От: Julien Rouhaud
Дата:
Сообщение: Re: Should we increase the default vacuum_cost_limit?