From: | Sami Imseih <samimseih(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PgStat_HashKey padding issue when passed by reference |
Date: | 2025-09-15 21:47:27 |
Message-ID: | CAA5RZ0sK61eY842rFgNy-NL_iTnQYZA0gnxdK6Zj3kNdeJb5gg@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > 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.
Just to confirm, you are saying we are unlikely to ever add a new field
to the key. Is that correct?
--
Sami Imseih
Amazon Web Services (AWS)
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitry Koval | 2025-09-15 22:11:19 | Re: Add SPLIT PARTITION/MERGE PARTITIONS commands |
Previous Message | Tom Lane | 2025-09-15 21:15:44 | Re: plan shape work |