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