From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | Aleksander Alekseev <aleksander(at)timescale(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: [PATCH] Support Int64 GUCs |
Date: | 2024-09-12 13:46:15 |
Message-ID: | ZuLwp8SLShYtd-Xo@nathan |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Sep 12, 2024 at 02:08:15PM +0300, Aleksander Alekseev wrote:
> Secondly, the following core GUCs are made 64-bit:
>
> ```
> autovacuum_freeze_min_age
> autovacuum_freeze_max_age
> autovacuum_freeze_table_age
> autovacuum_multixact_freeze_min_age
> autovacuum_multixact_freeze_max_age
> autovacuum_multixact_freeze_table_age
> ```
>
> I see several open questions with the patch in its current state.
>
> Firstly, I'm not sure if it is beneficial to affect the named GUCs out
> of the context of the larger patchset. Perhaps we have better GUCs
> that could benefit from being 64-bit? Or should we just leave alone
> the core GUCs and focus on providing DefineCustomInt64Variable() ?
I don't understand why we would want to make these GUCs 64-bit. All of the
allowed values fit in an int32, so AFAICT this would only serve to mislead
users into thinking they could set these much higher than they can/should.
TBH I'm quite skeptical that this would even be particularly useful for
extension authors. In what cases would a floating point value not suffice?
I'm not totally opposed to the idea of 64-bit GUCs, but I'd like more
information about the motivation.
--
nathan
From | Date | Subject | |
---|---|---|---|
Next Message | Matthias van de Meent | 2024-09-12 14:49:24 | Re: Adding skip scan (including MDAM style range skip scan) to nbtree |
Previous Message | Bertrand Drouvot | 2024-09-12 13:37:52 | Re: Switch PgStat_HashKey.objoid from Oid to uint64 |