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  (Ivan Trofimov <i.trofimow@yandex.ru>)
Список 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 по дате отправления:

Предыдущее
От: Alexander Pyhalov
Дата:
Сообщение: Re: Partial aggregates pushdown
Следующее
От: John Naylor
Дата:
Сообщение: Re: Change GUC hashtable to use simplehash?