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

From Tom Lane
Subject Re: WIP: Upper planner pathification
Date
Msg-id 10958.1456845736@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  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Teodor Sigaev <teodor@sigaev.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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: The plan for FDW-based sharding
Next
From: Alvaro Herrera
Date:
Subject: Re: Commitfest Bug (was: Re: Reusing abbreviated keys during second pass of ordered [set] aggregates)