Re: WIP: libpq: add a possibility to not send D(escribe) when executing a prepared statement

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.

In response to

Responses

Browse pgsql-hackers by date

  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