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
