Re: Proposal: Extending the PostgreSQL Protocol with Command Metadata
От | Jelte Fennema-Nio |
---|---|
Тема | Re: Proposal: Extending the PostgreSQL Protocol with Command Metadata |
Дата | |
Msg-id | CAGECzQRHxTWc_iOGn3hf_zNBeENaQLqrumUgZRhhRdAa2VRt+g@mail.gmail.com обсуждение исходный текст |
Ответ на | Proposal: Extending the PostgreSQL Protocol with Command Metadata (Kir Shatrov <sigkirs@gmail.com>) |
Список | 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 по дате отправления: