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
|
Список | 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 по дате отправления: