| From: | Chris Withers <chris(at)simplistix(dot)co(dot)uk> |
|---|---|
| To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
| Cc: | Jan Lentfer <Jan(dot)Lentfer(at)web(dot)de>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: pgbench tps drop from 5000 to 37 going from localhost to a server 13ms away |
| Date: | 2015-07-27 10:19:49 |
| Message-ID: | 55B605C5.3020907@simplistix.co.uk |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On 24/07/2015 22:51, Jeff Janes wrote:
> starting vacuum...end.
>
> transaction type: TPC-B (sort of)
> scaling factor: 1
>
>
> This is your problem. There is only one row in the pgbench_branch
> table, and every transaction has to update that one row. This is
> inherently a seriaized event.
Indeed it was!
> One solution is to just use a large scale on the benchmark so that
> they upate random pgbench_branch rows, rather than all updating the
> same row:
>
> pgbench -i -s50
With a scale of 1000, everything except the END took roughly the latency
time. Interestingly, the END still seems to take more, when
threads/clients are really ramped up (100 vs 8). Why would that be?
> Alternatively, you could write a custom file so that all 7 commands
> are sent down in one packet.
How would you restructure the sql so as the make that happen?
cheers,
Chris
| From | Date | Subject | |
|---|---|---|---|
| Next Message | papa | 2015-07-27 13:22:17 | Re: I lost my password |
| Previous Message | Herouth Maoz | 2015-07-27 09:16:54 | Connections closing due to "terminating connection due to administrator command" |