Re: Removing "long int"-related limit on hash table sizes
Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
From: ilmari@ilmari.org (Dagfinn Ilmari Mannsåker )
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Ranier Vilela <ranier.vf@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>,
Andres Freund <andres@anarazel.de>, Thomas Munro <thomas.munro@gmail.com>,
Jeff Davis <pgsql@j-davis.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-07-26T20:21:58Z
Lists: pgsql-hackers
Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > On 2021-Jul-25, Ranier Vilela wrote: > >> > BTW, one aspect of this that I'm unsure how to tackle is the >> > common usage of "L" constants; in particular, "work_mem * 1024L" >> > is a really common idiom that we'll need to get rid of. Not sure >> > that grep will be a useful aid for finding those. >> > >> I can see 30 matches in the head tree. (grep -d "1024L" *.c) > > grep grep '[0-9]L\>' -- *.[chyl] > shows some more constants. git grep -Eiw '(0x[0-9a-f]+|[0-9]+)U?LL?' -- *.[chyl] gives about a hundred more hits. We also have the (U)INT64CONST() macros, which are about about two thirds as common as the U?LL? suffixes. - ilmari
Commits
-
Get rid of artificial restriction on hash table sizes on Windows.
- b154ee63bb65 14.0 landed
- 2b8f3f5a7c0e 13.4 landed
- 28d936031a86 15.0 landed