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
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) |