Re: libpq: PQgetCopyData() and allocation overhead
| От | Jeroen Vermeulen |
|---|---|
| Тема | Re: libpq: PQgetCopyData() and allocation overhead |
| Дата | |
| Msg-id | CA+zULE6bV9yg9+=u0KAhjz-C_YpDr6bh5YknkffgqDHiKWugOg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: libpq: PQgetCopyData() and allocation overhead (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>) |
| Ответы |
Re: libpq: PQgetCopyData() and allocation overhead
|
| Список | pgsql-hackers |
Here's the patch (as a PR just to make it easy to read): https://github.com/jtv/postgres/pull/1
I don't have an easily readable benchmark yet, since I've been timing the potential impact on libpqxx. But can do that next.
Jeroen
On Fri, Feb 10, 2023, 11:26 Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> wrote:
On Fri, Feb 10, 2023 at 3:43 PM Jeroen Vermeulen <jtvjtv@gmail.com> wrote:
>
> Would there be interest in a variant of PQgetCopyData() that re-uses the same buffer for a new row, rather than allocating a new buffer on each iteration?
>
> I tried it on a toy benchmark, and it reduced client-side CPU time by about 12%. (Less of a difference in wall-clock time of course; the client was only using the CPU for a bit over half the time.)
Interesting. It might improve logical replication performance too as
it uses COPY protocol.
Do you mind sharing a patch, test case that you used and steps to
verify the benefit?
--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: