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

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

> Ranier Vilela <ranier(dot)vf(at)gmail(dot)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.

Sure, not a universal solution, I mean a start point.
When I look for a type that is signed and size 8 bytes in Windows, I only
see int64.

I think that most of these usages are concerned with
> memory sizes and would be better off as "size_t".

Ok, but let's not forget that size_t is unsigned.

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.
>
Sure.

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

File backend\access\gin\ginfast.c:
if (metadata->nPendingPages * GIN_PAGE_FREESIZE > cleanupSize *
1024L)
(accum.allocatedMemory >= workMemory * 1024L)))
Is it a good point to start?

or one more simple?
(src/backend/access/hash/hash.c) has one *long*.

regards,
Ranier Vilela