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 |
Subject: | Re: WIP: Upper planner pathification |
Date: | 2016-03-01 15:22:16 |
Message-ID: | 10958.1456845736@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:
>> I do not think the patch will make a lot of performance difference as-is;
>> its value is more in what it will let us do later. There are a couple of
> 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.
I think the default pgbench queries are too simple to have any possible
benefit from this patch. It does look like you're seeing some extra
planning time, which I think is likely due to redundant construction
of PathTargets. The new function set_pathtarget_cost_width() is not
very cheap, and in order to minimize the delta in this patch I did
not worry much about avoiding duplicate calls of it. That's another
thing in a long list of things to do later ;-). There might be other
pain points I haven't recognized yet.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2016-03-01 15:23:49 | Re: Commitfest Bug (was: Re: Reusing abbreviated keys during second pass of ordered [set] aggregates) |
Previous Message | Robert Haas | 2016-03-01 15:19:45 | Re: The plan for FDW-based sharding |