From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Teaching users how they can get the most out of HOT in Postgres 14 |
Date: | 2021-05-13 12:06:55 |
Message-ID: | 20210513120655.GZ27406@telsasoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, May 13, 2021 at 04:27:47PM +0900, Michael Paquier wrote:
> On Tue, May 11, 2021 at 04:42:27PM +0900, Michael Paquier wrote:
> > Whatever the solution chosen, the thing I can see we agree on here is
> > that we need to do something, at least in the shape of an on/off
> > switch to have an escape path in case of problems. Peter, could we
> > get something by beta1 for that? FWIW, I would use a float GUC to
> > control that, and not a boolean switch, but I am just one voice here,
> > and that's not a feature I worked on.
>
> So, I have been thinking more about this item, and a boolean switch
> still sounded weird to me, so attached is a patch to have two GUCs,
> one for manual VACUUM and autovacuum like any other parameters, to
> control this behavior, with a default set at 2% of the number of
> relation pages with dead items needed to do the index cleanup work.
>
> Even if we switch the parameter type used here, the easiest and most
> consistent way to pass down the parameter is just to use VacuumParams
> set within ExecVacuum() and the autovacuum code path. The docs need
> more work, I guess.
>
> Thoughts?
> + cleanup_index_scale_factor = autovacuum_cleanup_index_scale >= 0 ?
> + autovacuum_cleanup_index_scale : VacuumCostDelay;
CostDelay is surely not what you meant.
> + <title>Vacuum parameters for Indexes</title>
> + <para>
> + During the execution of <xref linkend="sql-vacuum"/>
> + and <xref linkend="sql-analyze"/>
"and analyze" is wrong?
> + This parameter can only be set in the <filename>postgresql.conf</filename>
> + file or on the server command line.
It's SIGHUP
> + This parameter can only be set in the <filename>postgresql.conf</filename>
> + file or on the server command line.
Same
+ {
+ {"vacuum_cleanup_index_scale_factor", PGC_SIGHUP, VACUUM_INDEX,
+ gettext_noop("Fraction of relation pages, with at least one dead item, required to clean up indexes."),
+ NULL
+ },
+ &VacuumCleanupIndexScale,
+ 0.02, 0.0, 0.05,
+ NULL, NULL, NULL
+ },
Why is the allowed range from 0 to 0.05? Why not 0.10 or 1.0 ?
The old GUC of the same name had max 1e10.
I think a reduced range and a redefinition of the GUC would need to be called
out as an incompatibility.
Also, the old GUC (removed at 9f3665fbf) had:
- {"vacuum_cleanup_index_scale_factor", PGC_USERSET, CLIENT_CONN_STATEMENT,
I think USERSET and STATEMENT were right ?
Alternately, what if this were in the DEVELOPER category, which makes this
easier to remove in v15.
--
Justin
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2021-05-13 12:09:33 | Re: Inherited UPDATE/DELETE vs async execution |
Previous Message | Dilip Kumar | 2021-05-13 11:48:52 | Re: RFC: Logging plan of the running query |