Re: [HACKERS] PATCH: Batch/pipelining support for libpq
От | Craig Ringer |
---|---|
Тема | Re: [HACKERS] PATCH: Batch/pipelining support for libpq |
Дата | |
Msg-id | CAMsr+YGZvfppLW3JQThg_yT_1GnkT4G9BtongDXmQRUO0Lqz4g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] PATCH: Batch/pipelining support for libpq (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
On 22 Jun. 2017 07:40, "Andres Freund" <andres@anarazel.de> wrote:
On 2017-06-20 17:51:23 +0200, Daniel Verite wrote:This is seriously impressive. Just using the normal pgbench mixed
> Andres Freund wrote:
>
> > FWIW, I still think this needs a pgbench or similar example integration,
> > so we can actually properly measure the benefits.
>
> Here's an updated version of the patch I made during review,
> adding \beginbatch and \endbatch to pgbench.
> The performance improvement appears clearly
> with a custom script of this kind:
> \beginbatch
> UPDATE pgbench_branches SET bbalance = bbalance + 1 WHERE bid = 0;
> ..above repeated 1000 times...
> \endbatch
>
> versus the same with a BEGIN; END; pair instead of \beginbatch \endbatch
>
> On localhost on my desktop I tend to see a 30% difference in favor
> of the batch mode with that kind of test.
> On slower networks there are much bigger differences.
workload, wrapping a whole transaction into a batch *doubles* the
throughput. And that's locally over a unix socket - the gain over
actual network will be larger.
In my original tests I got over a 300x improvement on WAN :) . I should check if the same applies with pgbench.
В списке pgsql-hackers по дате отправления: