Re: protocol support for labels
От | Jeremy Schneider |
---|---|
Тема | Re: protocol support for labels |
Дата | |
Msg-id | C9B3F44D-C90F-4A91-A34B-A09F4FBE58E9@ardentperf.com обсуждение исходный текст |
Ответ на | Re: protocol support for labels (Kirill Reshke <reshkekirill@gmail.com>) |
Ответы |
Re: protocol support for labels
|
Список | pgsql-hackers |
> On Mar 11, 2025, at 3:03 AM, Kirill Reshke <reshkekirill@gmail.com> wrote: > > On Tue, 11 Mar 2025 at 11:09, Jeremy Schneider <schneider@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 changesto 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 opinionsabout how queries should be jumbled (eg if comment_stats needs different tweaks than sqlcommenter)? Was there previousdiscussion about this already? I’ll need to go search mailing list history a bit -Jeremy Sent from my TI-83
В списке pgsql-hackers по дате отправления: