From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: WIP: Upper planner pathification |
Date: | 2016-03-03 00:10:53 |
Message-ID: | 23314.1456963853@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Teodor Sigaev <teodor(at)sigaev(dot)ru> writes:
> Yep, for now on my notebook (best from 5 tries):
> % pgbench -i -s 3000
> % pgbench -s 3000 -c 4 -j 4 -P 1 -T 60
> HEAD 569 tps
> patched 542 tps
> % pgbench -s 3000 -c 4 -j 4 -P 1 -T 60 -S
> HEAD 9500 tps
> patched 9458 tps
> Looks close to measurement error, but may be explained increased amount
> of work for planning. Including, may be, more complicated path tree.
Hmmm ... I'm now wondering about the "measurement error" theory.
I tried to repeat this measurement locally, focusing on the select-only
number since that should have a higher ratio of planning time to
execution.
Test setup:
cassert-off build
pgbench -i -s 100
sudo cpupower frequency-set --governor performance
repeat 3 times: pgbench -c 4 -j 4 -P 5 -T 60 -S
HEAD:
tps = 32508.217002 (excluding connections establishing)
tps = 33081.402766
tps = 32520.859913
average of 3: 32703 tps
WITH PATCH:
tps = 32815.922160 (excluding connections establishing)
tps = 33312.149718
tps = 32784.527489
average of 3: 32970 tps
(Hardware: dual quad-core Xeon E5-2609, running current RHEL6)
So I see no evidence for a slowdown on pgbench's SELECT queries.
Anybody else want to check performance on simple scan/join queries?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-03-03 00:24:11 | Re: jsonb array-style subscription |
Previous Message | Jim Nasby | 2016-03-02 23:57:27 | Re: Freeze avoidance of very large table. |