On Wed, Sep 03, 2025 at 02:48:40PM +0200, Peter Eisentraut wrote:
> Taking a look at your previous patch with the changes from long to int64, I
> think there is something that still doesn't fit.
>
> For example, taking a look at the callers of hash_estimate_size(int64,
> Size), they pass either int as the first argument, or in a few cases long.
> Looking around inside dynahash.c, do any of these places actually need the
> int64 range? These are all just counters, the memory sizes use Size
> correctly it seems. Do we want to support more than INT_MAX elements? I
> wonder whether the right solution would be to turn the long uses into int
> instead. Then you also don't need to deal with two next_pow2* variants.
In terms of in-core callers, I am not worried. The highest cap that
can be reached would be I think PGSS, and we are capped by the
pgss_max GUC at (INT_MAX / 2).
hash_create() is too generic to offer hints at Postgres-related uses
outside of core. hash_get_num_entries() and hash_select_dirsize()
offer a couple of more dedicated hints, but everything I am seeing
seems to point out to the argument that the tables are capped due to
integer GUCs being 4 bytes, or use some hardcoded values which are
much lower than the 2^32 limit, like some stuff in this repo:
https://github.com/jithinjose2004/postgres_cluster/
So I could agree with your argument of dropping the 8-byte part
altogether argument and restrict all the interfaces to 4 bytes. Any
comments or opinions from others in favor or against taking this Leap
of Faith?
--
Michael
