Re: WIP: Upper planner pathification

On Tue, Mar 1, 2016 at 10:22 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.

Yikes.  The read-only test is an 0.5% hit which isn't great, but the
read-write test is about 5% which I think is clearly not OK.  What's
your plan for doing something about that?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company