Re: [PATCH] Support Int64 GUCs

Поиск
Список
Период
Сортировка
От Nathan Bossart
Тема Re: [PATCH] Support Int64 GUCs
Дата
Msg-id ZvLRJPcI4hCTF5Kw@nathan
обсуждение исходный текст
Ответ на Re: [PATCH] Support Int64 GUCs  (Alexander Korotkov <aekorotkov@gmail.com>)
Список pgsql-hackers
On Tue, Sep 24, 2024 at 12:27:20PM +0300, Aleksander Alekseev wrote:
>> It doesn't look like these *_age GUCs could benefit from being 64-bit,
>> before 64-bit transaction ids get in.  However, I think there are some
>> better candidates.
>>
>> autovacuum_vacuum_threshold
>> autovacuum_vacuum_insert_threshold
>> autovacuum_analyze_threshold
>>
>> This GUCs specify number of tuples before vacuum/analyze.  That could
>> be more than 2^31.  With large tables of small tuples, I can't even
>> say this is always impractical to have values greater than 2^31.
>
> [...]
> 
> I found a great candidate in src/test/modules/delay_execution:
> 
> ```
>     DefineCustomIntVariable("delay_execution.post_planning_lock_id",
>                             "Sets the advisory lock ID to be
> locked/unlocked after planning.",
> ```
> 
> Advisory lock IDs are bigints [1]. I modified the module to use Int64's.
> 
> I guess it may also answer Nathan's question.

Hm.  I'm not sure I find any of these to be particularly convincing
examples of why we need int64 GUCs.  Yes, the GUCs in question could
potentially be set to higher values, but I've yet to hear of this being a
problem in practice.  We might not want to encourage such high values,
either.

-- 
nathan



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