From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: subscription worker signalling wal writer too much |
Date: | 2017-06-20 18:31:48 |
Message-ID: | CAMkU=1xBiqfLR+=h+hqKsxnZay4kwhVzu0kCShxsNggdqqdRFg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jun 15, 2017 at 3:06 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>
> This new patch is simpler than the previous one, and more effective at
> speeding up replication. I assume it would speed up pgbench with
> synchronous_commit turned off (or against unlogged tables) as well, but I
> don't think I have the hardware needed to test that.
>
If I use the 'tpcb-func' script embodied in the attached patch to pgbench,
then I can see the performance difference against unlogged tables using 8
clients on a 8 CPU virtual machine. The normal tpcb-like script has too
much communication overhead, bouncing from pgbench to the postgres backend
7 times per transaction, to see the difference. I also had to
make autovacuum_vacuum_cost_delay=0, otherwise auto analyze holds a
snapshot long enough to bloat the HOT chains which injects a great deal of
variability into the timings.
Commit 7975c5e0a992ae9 in the 9.6 branch causes a regression of about 10%,
and the my patch from the previous email redeems that regression. It also
gives the same improvement against 10dev HEAD.
Cheers,
Jeff
Attachment | Content-Type | Size |
---|---|---|
pgbench_function.patch | application/octet-stream | 1.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2017-06-20 18:32:47 | Re: Fix a typo in partition.c |
Previous Message | Peter Eisentraut | 2017-06-20 18:30:58 | Re: Missing comment for ResultRelInfo in execnodes.h |