Re: Removing "long int"-related limit on hash table sizes

Поиск
Список
Период
Сортировка
От Ranier Vilela
Тема Re: Removing "long int"-related limit on hash table sizes
Дата
Msg-id CAEudQApp_3zV+Twq6NiF3bJx3ZoktM=XyK1Q+Mfc17pY3xdxEA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Removing "long int"-related limit on hash table sizes  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Removing "long int"-related limit on hash table sizes
Список pgsql-hackers
Em dom., 25 de jul. de 2021 às 13:28, Tom Lane <tgl@sss.pgh.pa.us> escreveu:
Andres Freund <andres@anarazel.de> writes:
> On 2021-07-23 17:15:24 -0400, Tom Lane wrote:
>> That's because they spill to disk where they did not before.  The easy
>> answer of "raise hash_mem_multiplier" doesn't help, because on Windows
>> the product of work_mem and hash_mem_multiplier is clamped to 2GB,
>> thanks to the ancient decision to do a lot of memory-space-related
>> calculations in "long int", which is only 32 bits on Win64.

> We really ought to just remove every single use of long.

I have no objection to that as a long-term goal.  But I'm not volunteering
to do all the work, and in any case it wouldn't be a back-patchable fix.
I'm a volunteer, if you want to work together.
I think int64 is in most cases the counterpart of *long* on Windows.

regards,
Ranier Vilela

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

Предыдущее
От: Julien Rouhaud
Дата:
Сообщение: Re: Planning counters in pg_stat_statements (using pgss_store)
Следующее
От: Justin Pryzby
Дата:
Сообщение: Re: when the startup process doesn't (logging startup delays)