Re: [HACKERS] PATCH: Batch/pipelining support for libpq
От | Daniel Verite |
---|---|
Тема | Re: [HACKERS] PATCH: Batch/pipelining support for libpq |
Дата | |
Msg-id | 0f45911d-538a-4571-aa58-8cfa89bbf548@manitou-mail.org обсуждение исходный текст |
Ответ на | Re: [HACKERS] PATCH: Batch/pipelining support for libpq (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: [HACKERS] PATCH: Batch/pipelining support for libpq
|
Список | pgsql-hackers |
Andres Freund wrote: - if (pqFlush(conn) < 0) - goto sendFailed; + if (conn->batch_status == PQBATCH_MODE_OFF) + { + /* + * Give the data a push. In nonblock mode, don't complain if we're unable + * to send it all; PQgetResult() will do any additional flushing needed. + */ + if (pqFlush(conn) < 0) + goto sendFailed; + } Seems to be responsible for roughly an 1.7x speedup in tps and equivalent decrease in latency, based on the "progress" info. I wonder how much of that corresponds to a decrease in the number of packets versus the number of syscalls. Both matter, I guess. But OTOH there are certainly batch workloads where it will be preferrable for the first query to reach the server ASAP, rather than waiting to be coalesced with the next ones. libpq is not going to know what's best. One option may be to leave that decision to the user by providing a PQBatchAutoFlush(true|false) property, along with a PQBatchFlush() function. Maybe we could even let the user set the size of the sending buffer, so those who really want to squeeze performance may tune it for their network and workload. Best regards, -- Daniel Vérité PostgreSQL-powered mailer: http://www.manitou-mail.org Twitter: @DanielVerite
В списке pgsql-hackers по дате отправления: