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?
Whether artefact of test, or real problem, clearly something fixable.
ISTM that we are clearly "going for it"; everybody agrees we should apply the patch now.
The longer we hold off on applying it, the longer we wait for dependent changes.
My vote is apply it early (i.e. now!) and clean up as we go.
--
Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
