On Thu, Sep 11, 2025 at 10:21:45AM -0500, Sami Imseih wrote:
> I don't see how this improves the situation, but will just make it more
> difficult to add a new field that requires padding in the future.
>
> If we are documenting either way, I rather that we just document the need
> to pass a key by reference, which is the pattern used in other areas
> ( see pgss_store and entry_alloc in pg_stat_statements.c )
>
> Others may have a different opinion.
Yeah, I do care about the size of the hash key. So if someone goes on
and proposes the addition of a new field while we already have 8 bytes
for the object ID, that can itself be the hash of something else
because we area already set up for life in terms of value friction, we
will have an interesting debate. Adding padding is not something I'd
be OK with, even if the hash key compaction could be enforced with a
compiler attribute.
And FWIW, I'm not much a fan of the expectations documented at the top
of pgssHashKey with its padding bytes, neither am I convinced that it
is a good idea to spread that more than necessary and bloat the size
of the hash key. That's just my opinion, other opinions may differ of
course, and I'm OK to be outvoted.
--
Michael
