Re: Proposal: Extending the PostgreSQL Protocol with Command Metadata - Mailing list pgsql-hackers

From Jelte Fennema-Nio
Subject Re: Proposal: Extending the PostgreSQL Protocol with Command Metadata
Date
Msg-id CAGECzQRHxTWc_iOGn3hf_zNBeENaQLqrumUgZRhhRdAa2VRt+g@mail.gmail.com
Whole thread Raw
In response to Proposal: Extending the PostgreSQL Protocol with Command Metadata  (Kir Shatrov <sigkirs@gmail.com>)
List pgsql-hackers
On Mon, 18 Aug 2025 at 02:25, Kir Shatrov <sigkirs@gmail.com> wrote:
> I'd like to propose a backward-compatible extension to the PostgreSQL Frontend/Backend Protocol that would allow
serversto send command metadata back to clients alongside query results.
 

I think at least one of your goals for the feature makes sense:
Allowing to debug query performance of the query that you have run.
Currently that's only possible with having to rely on EXPLAIN (which
does not return the query results) or autoexplain which requires
access to the server logs. This would allow these stats to be added to
distributed trace spans etc by an application.

A few thoughts on the actual proposal:
1. I think we'd want the result to be JSON so it's easily parseable by
applications
2. I've discussed a similar idea in the past at a conference: allow
continuous (partial) explain analyze plans to be sent by the server to
the client at a specific interval during query execution. So that a
client can use that info to show some kind of progress bar. I think it
would be good to keep that usecase in mind when designing a protocol
extension like this, so that we could later extend it.
3. I think you could create a POC for this in a Postgres extension
without changing the protocol by piggybacking on GUC_REPORT and the
ParameterStatus message. If you create an extension that adds a GUC
with the GUC_REPORT flag, and set that GUC to a JSON string with the
information that you want at the end of a query execution. Then I
think you basically get the functionality that you want.
4. I agree with Jacob, that if we want people to be able to choose the
exact information that they want in these messages, then that would
need to be done at the protocol level. That way proxies could filter
out the things that the client don't want, but they did.



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Adding REPACK [concurrently]
Next
From: Nazir Bilal Yavuz
Date:
Subject: Re: Speed up COPY FROM text/CSV parsing using SIMD