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

From: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Removing "long int"-related limit on hash table sizes
Date: 2021-07-25 17:19:26
Message-ID: CAEudQApp_3zV+Twq6NiF3bJx3ZoktM=XyK1Q+Mfc17pY3xdxEA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Em dom., 25 de jul. de 2021 às 13:28, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> escreveu:

> Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2021-07-25 17:56:54 Re: when the startup process doesn't (logging startup delays)
Previous Message Julien Rouhaud 2021-07-25 17:08:08 Re: Planning counters in pg_stat_statements (using pgss_store)