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: | Raw Message | Whole Thread | 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 |