Re: Removing "long int"-related limit on hash table sizes
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Ranier Vilela <ranier.vf@gmail.com>
Cc: 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-25T18:53:16Z
Lists: pgsql-hackers
Ranier Vilela <ranier.vf@gmail.com> writes: > I think int64 is in most cases the counterpart of *long* on Windows. I'm not particularly on board with s/long/int64/g as a universal solution. I think that most of these usages are concerned with memory sizes and would be better off as "size_t". We might need int64 in places where we're concerned with sums of memory usage across processes, or where the value needs to be allowed to be negative. So it'll take case-by-case analysis to do it right. 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. regards, tom lane
Commits
-
Get rid of artificial restriction on hash table sizes on Windows.
- b154ee63bb65 14.0 landed
- 2b8f3f5a7c0e 13.4 landed
- 28d936031a86 15.0 landed