From: | Frits Hoogland <frits(dot)hoogland(at)gmail(dot)com> |
---|---|
To: | Jeremy Schneider <schneider(at)ardentperf(dot)com> |
Cc: | Kirill Reshke <reshkekirill(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Dave Cramer <davecramer(at)postgres(dot)rocks> |
Subject: | Re: protocol support for labels |
Date: | 2025-03-11 16:23:14 |
Message-ID: | 1D94947A-BF4D-4FDF-AA86-91C6D18F5AAE@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 <schneider(at)ardentperf(dot)com> wrote:
>
>
>> On Mar 11, 2025, at 3:03 AM, Kirill Reshke <reshkekirill(at)gmail(dot)com> wrote:
>>
>> On Tue, 11 Mar 2025 at 11:09, Jeremy Schneider <schneider(at)ardentperf(dot)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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Dean Rasheed | 2025-03-11 16:32:09 | Re: Wrong results with subquery pullup and grouping sets |
Previous Message | David G. Johnston | 2025-03-11 16:18:09 | Re: DOCS: Make the Server Application docs synopses more consistent |