From: | Nico Williams <nico(at)cryptonector(dot)com> |
---|---|
To: | Jeremy Schneider <schneider(at)ardentperf(dot)com> |
Cc: | Frits Hoogland <frits(dot)hoogland(at)gmail(dot)com>, Kirill Reshke <reshkekirill(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Dave Cramer <davecramer(at)postgres(dot)rocks>, Sami Imseih <samimseih(at)gmail(dot)com> |
Subject: | Re: protocol support for labels |
Date: | 2025-03-13 15:04:58 |
Message-ID: | Z9L0Goq97SXQAyX0@ubby |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Mar 12, 2025 at 11:39:57PM -0700, Jeremy Schneider wrote:
> Isn't multiple queries in one packet only possible with the simple
> protocol, but not possible with the extended protocol? So this would be
> entirely incompatible with prepared/parameterized statements?
It's TCP. Packet and segment boundaries are not exposed to the
application, so PG doesn't know that you sent "two queries in one
packet" (or in one segment). It just reads one query, processes it,
then it reads the next one, processes it, etc.
So all that's needed here is for a well-defined GUC that can be set with
set_config() and whose purpose is to decorate subsequent queries in
pg_stat_statements and/or logs. You could set it once for all your
queries or once per-query -- whatever.
As long as the client-side API can batch one of these calls to
set_config() followed by the actual query you want to do in the same
write() on the socket (TCP_CORK helps) then this idea will be barely
noticeable performance-wise.
Nico
--
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2025-03-13 15:27:39 | Re: A few patches to clarify snapshot management |
Previous Message | Thomas Munro | 2025-03-13 14:58:52 | Re: Some read stream improvements |