Re: [HACKERS] Performance degradation in TPC-H Q18
От | Kuntal Ghosh |
---|---|
Тема | Re: [HACKERS] Performance degradation in TPC-H Q18 |
Дата | |
Msg-id | CAGz5QC+jMx8x-cWSQt9JHgioaYG4-fBTSNG+mQ3O0dWZQup4PQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Performance degradation in TPC-H Q18 (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On Sat, Mar 4, 2017 at 11:09 AM, Robert Haas <robertmhaas@gmail.com> wrote: > On Sat, Mar 4, 2017 at 5:56 AM, Andres Freund <andres@anarazel.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
В списке pgsql-hackers по дате отправления: