Re: WIP: Upper planner pathification - Mailing list pgsql-hackers

From Tom Lane
Subject Re: WIP: Upper planner pathification
Date
Msg-id 23314.1456963853@sss.pgh.pa.us
Whole thread Raw
In response to Re: WIP: Upper planner pathification  (Teodor Sigaev <teodor@sigaev.ru>)
Responses Re: WIP: Upper planner pathification
Re: WIP: Upper planner pathification
List pgsql-hackers
Teodor Sigaev <teodor@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



pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: Freeze avoidance of very large table.
Next
From: Tom Lane
Date:
Subject: Re: jsonb array-style subscription