Re: Should we increase the default vacuum_cost_limit? - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: Should we increase the default vacuum_cost_limit?
Date
Msg-id CAOBaU_Z8k1RAB8u761qg-L9EKZzywwiJde=hiuBRN6hvE8+7vQ@mail.gmail.com
Whole thread Raw
In response to Re: Should we increase the default vacuum_cost_limit?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Should we increase the default vacuum_cost_limit?
Re: Should we increase the default vacuum_cost_limit?
List 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 by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: [HACKERS] PATCH: multivariate histograms and MCV lists
Next
From: Julien Rouhaud
Date:
Subject: Re: Should we increase the default vacuum_cost_limit?