On Mon, Dec 8, 2025 at 12:27 PM Bertrand Drouvot
<[email protected]> wrote:
>
> Hi,
>
> On Mon, Dec 08, 2025 at 12:12:27PM +0200, Heikki Linnakangas wrote:
> > On 08/12/2025 11:54, Jakub Wartak wrote:
>
> Thanks for working on this!
>
> > > 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?
>
> I worked on something similar in the past (see [1]) and ended up providing 
> the extra
> information that way:
>
>    pid   | wait_event_type |  wait_event  |                            infos
> ---------+-----------------+--------------+-------------------------------------------------------------
>  2560105 | IO              | DataFileRead | {"blocknum" : "9272", "dbnode" : 
> "5", "relnode" : "16407"}
>  2560135 | IO              | WalSync      | {"segno" : "1", "tli" : "1"}
>  2560138 | IO              | DataFileRead | {"blocknum" : "78408", "dbnode" : 
> "5", "relnode" : "16399"}
>
> The "descriptions" were added in wait_event_names.txt, for example,
>
> +DATA_FILE_READ "Waiting for a read from a relation data file." "blocknum"  
> "dbnode"    "relnode"
>
> and the json was build only at query time. Maybe that could be an option to 
> expose
> the values and the descriptions in the same field.
>
> [1]: 
> https://www.postgresql.org/message-id/[email protected]

Hi Bertrand, thanks for the link. I've responded to Heikki, but Your
thread (and feedback You got) was one of the directions of why not to
add anything there beyond just using a more powerful(longer) registry
for free.

-J.


Reply via email to