Teodor Sigaev <teo...@sigaev.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
