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

Поиск
Список
Период
Сортировка
От Ivan Trofimov
Тема WIP: libpq: add a possibility to not send D(escribe) when executing a prepared statement
Дата
Msg-id 82c438b4-d91c-9009-65fc-593124d5a277@yandex.ru
обсуждение исходный текст
Ответы Re: WIP: libpq: add a possibility to not send D(escribe) when executing a prepared statement  ("Andrey M. Borodin" <x4mmm@yandex-team.ru>)
Список pgsql-hackers
Hi!


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) .


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. Doing it this way saves

a measurable amount of CPU for both client and server and saves a lot of 
network traffic, for example:

when selecting a single row from a table with 30 columns, where each 
column has 10-symbols name, and

every value in a row is a 10-symbols TEXT, i'm seeing an amount of bytes 
sent to client decreased

by a factor of 2.8, and the CPU time client spends in userland decreased 
by a factor of ~1.5.


The patch attached adds a family of functions

PQsendQueryPreparedPredescribed, PQgetResultPredescribed, 
PQisBusyPredescribed,

which allow a user to do just that.

If the idea seems reasonable i'd be happy to extend these to 
PQexecPrepared as well and cover it with tests.


P.S. This is my first time ever sending a patch via email, so please 
don't hesitate to point at mistakes

i'm doing in the process.

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Nathan Bossart
Дата:
Сообщение: Re: common signal handler protection
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] legitimacy of using PG_TRY , PG_CATCH , PG_END_TRY in C function