Re: protocol support for labels

From: Dave Cramer <davecramer(at)postgres(dot)rocks>
To: Frits Hoogland <frits(dot)hoogland(at)gmail(dot)com>
Cc: Jeremy Schneider <schneider(at)ardentperf(dot)com>, Kirill Reshke <reshkekirill(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: protocol support for labels
Date: 2025-03-11 18:56:43
Message-ID: CADK3HHLTArbJJgcifK-8vCGwvKEoBx1f5-xP8qwRiSxA3LR2=g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dave Cramer
www.postgres.rocks

On Tue, 11 Mar 2025 at 12:23, Frits Hoogland <frits(dot)hoogland(at)gmail(dot)com>
wrote:

> 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
>
>
Jeremy,

Thanks for this. I am hoping to get consensus of ideas for changes to the
protocol.
Please join the discussion here https://discord.gg/bWum3hbM as well.

Krill, change starts with requests and without them nothing will happen.
Please post your ideas.

Dave

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nico Williams 2025-03-11 19:03:12 Re: protocol support for labels
Previous Message Thomas Munro 2025-03-11 18:35:46 Re: Some read stream improvements