Re: Performance degradation in TPC-H Q18

On Sat, Mar 4, 2017 at 11:09 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Sat, Mar 4, 2017 at 5:56 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>> attached is a patch to address this problem, and the one reported by
>> Dilip. I ran a lot of TPC-H and other benchmarks, and so far this
>> addresses all the performance issues, often being noticeably faster than
>> with the dynahash code.
>>
>> Comments?
+ errdetail("size %f/members %f: factor %.2f",
+ (double)tb->size, (double)tb->members,
+ (double) tb->members / tb->size),
In SH_STAT, we use 'filled' instead of 'factor'. For displaying size
and members, there is no need to convert those into double.

> I'm still not convinced that raising the fillfactor like this is going
> to hold up in testing, but I don't mind you committing it and we'll
> see what happens. If it is possible to survive with a fillfactor that
> high, it certainly has some advantages, and it's obviously more likely
> to work out with the other logic you've added. I think we need a lot
> more people playing with this to know whether any given approach is
> right, and I think getting something committed will help more than any
> amount of theoretical discussion.
+1

> I think DEBUG1 is far too high for something that could occur with
> some frequency on a busy system; I'm fairly strongly of the opinion
> that you ought to downgrade that by a couple of levels, say to DEBUG3
> or so.
+1

I've tested with TPC-H query 18 and it's working fine.

--
Thanks & Regards,
Kuntal Ghosh
EnterpriseDB: http://www.enterprisedb.com