On 08/12/2025 11:54, Jakub Wartak wrote:
> While thinking about cons, the only cons that I could think of is that
> when we would be exposing something as 32-bits , then if the following
> major release changes some internal structure/data type to be a bit
> more heavy, it couldn't be exposed anymore like that (think of e.g.
> 64-bit OIDs?)
>
> Any help, opinions, ideas and code/co-authors are more than welcome.
Expanding it to 64 bit seems fine as far as performance is concerned. I
think the difficult and laborious part is to design the facilities to
make use of it. For example, if you encode an table OID in it, how do
you interpret that when you're looking at pg_stat_activity? A new
pg_explain_wait_event(bigint waitevent) that returns a text
representation of the event perhaps? Wait events can be defined in
extensions; how does an extension plug into this facility?
Inevitably, the extra 32 bits won't be enough to expose everything that
you might want to expose. Should we already think about what to do then?
For lock waits, for example, should we have another array in shared
memory with more details, and just store an offset into that array in
the extra wait event bits, for example? (e already have pg_locks, but
let's imagine we didn't. How would you design it in a green field scenario?
- Heikki
