The usecase that I think might be useful is to have a database client send metadata along with a query. This partially is possible today by setting application_name, but that is a separate request, it would be great if that could be sent along with the query in one go. Another option to pass metadata is to add a comment (/* .. */), but a comment cannot be set for a prepared statement, because the statement is prepared first and then later invoked on runtime, which executes a query that is fixed.
Frits Hoogland > On 11 Mar 2025, at 15:49, Jeremy Schneider <schnei...@ardentperf.com> wrote: > > >> On Mar 11, 2025, at 3:03 AM, Kirill Reshke <reshkekir...@gmail.com> wrote: >> >> On Tue, 11 Mar 2025 at 11:09, Jeremy Schneider <schnei...@ardentperf.com> >> wrote: >> >>> observability frameworks like OpenTelemetry support tracing through all >>> layers of a stack, and trace_ids can even be passed into sql with >>> extensions like sqlcommenter. however sqlcommenter puts the trace_id >>> into a comment which effectively breaks all the utility of >>> pg_stat_statements since each query has a unique trace_id. >>> >> There are some other use-cases: >> 1) RO-RW routing. Users can pass target-session-attrs to the server >> within query labels to hint about its need. Useful when some kind of >> proxy (odyssey,pgbouncer,spqr,pgpool II, pgcat, pg_doorman) is used. >> 2) pg_comment_stats uses comments in the query to accumulate statistics. [0] > > > Thinking a bit more, my root issue is specifically around pg_stat_statements > so maybe it’s also solvable with some changes to how query jumbling is done > > But that topic seems like one where we’d never get consensus > > Should query jumbling for calculating query_id be customizable somehow? How > would we resolve multiple concurrent opinions about how queries should be > jumbled (eg if comment_stats needs different tweaks than sqlcommenter)? Was > there previous discussion about this already? I’ll need to go search mailing > list history a bit > > -Jeremy > > > Sent from my TI-83 >
