| 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: | Whole Thread | Raw Message | 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 |