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

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

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

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