Re: PgStat_HashKey padding issue when passed by reference
От | Michael Paquier |
---|---|
Тема | Re: PgStat_HashKey padding issue when passed by reference |
Дата | |
Msg-id | aMNuDt8yP7lws4CE@paquier.xyz обсуждение исходный текст |
Ответ на | Re: PgStat_HashKey padding issue when passed by reference (Sami Imseih <samimseih@gmail.com>) |
Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: