On Tue, Mar 1, 2016 at 10:22 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Teodor Sigaev <teo...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
