Re: WIP: libpq: add a possibility to not send D(escribe) when executing a prepared statement
От | Andrey M. Borodin |
---|---|
Тема | Re: WIP: libpq: add a possibility to not send D(escribe) when executing a prepared statement |
Дата | |
Msg-id | 6E9981D0-F66B-4102-8D6E-E85C7F2BD77B@yandex-team.ru обсуждение исходный текст |
Ответ на | WIP: libpq: add a possibility to not send D(escribe) when executing a prepared statement (Ivan Trofimov <i.trofimow@yandex.ru>) |
Ответы |
Re: WIP: libpq: add a possibility to not send D(escribe) when executing a prepared statement
|
Список | pgsql-hackers |
Hi Ivan, thank you for the patch. > On 22 Nov 2023, at 03:58, Ivan Trofimov <i.trofimow@yandex.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.
В списке pgsql-hackers по дате отправления: