| From: | "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru> |
|---|---|
| To: | Ivan Trofimov <i(dot)trofimow(at)yandex(dot)ru> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: WIP: libpq: add a possibility to not send D(escribe) when executing a prepared statement |
| Date: | 2023-11-22 06:46:27 |
| Message-ID: | 6E9981D0-F66B-4102-8D6E-E85C7F2BD77B@yandex-team.ru |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Ivan,
thank you for the patch.
> On 22 Nov 2023, at 03:58, Ivan Trofimov <i(dot)trofimow(at)yandex(dot)ru> wrote:
>
> Currently libpq sends B(ind), D(escribe), E(execute), S(ync) when executing a prepared statement.
> The response for that D message is a RowDescription, which doesn't change during prepared
> statement lifetime (with the attributes format being an exception, as they aren't know before execution) .
From my POV the idea seems reasonable (though I’m not a real libpq expert).
BTW some drivers also send Describe even before Bind. This creates some fuss for routing connection poolers.
> In a presumably very common case of repeatedly executing the same statement, this leads to
> both client and server parsing/sending exactly the same RowDescritpion data over and over again.
> Instead, library user could acquire a statement result RowDescription once (via PQdescribePrepared),
> and reuse it in subsequent calls to PQexecPrepared and/or its async friends.
But what if query result structure changes? Will we detect this error gracefully and return correct error?
Best regards, Andrey Borodin.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | John Naylor | 2023-11-22 07:09:12 | Re: Change GUC hashtable to use simplehash? |
| Previous Message | Alexander Pyhalov | 2023-11-22 06:32:58 | Re: Partial aggregates pushdown |