On Tue, Feb 28, 2017 at 11:16 PM, Andres Freund <andres@anarazel.de> wrote:
>> To me, it seems like a big problem that we have large, unfixed
>> performance regressions with simplehash four months after it went in.
>
> Yea, I agree. I'm fairly sure that the patch I posted in that thread
> actually fixes the issue (and would also have made already applied hash
> patch of yours a small-ish optimization). I held back back because I
> disliked the idea of magic constants, and I couldn't figure out a way to
> properly "derive" them - but I'm inclined to simply live with the magic constsnts.
I think it's better to push in a proposed fix and see how it holds up
than to leave the tree in an unfixed state for long periods of time.
If the fix is good, then the fact that there's a magic constant
doesn't really matter all that much, and it can always be improved
later. On the other hand, if the fix is bad, pushing it improves the
chances of finding the problems. Not many people are going to test an
uncommitted fix.
BTW, another option to consider is lowering the target fillfactor.
IIRC, Kuntal mentioned to me that cranking it down seemed to fix the
issue. Obviously, it's better to detect when we need a lower
fillfactor than to always use a lower one, but obviously the tighter
you pack the hash table, the more likely it is that you're going to
have these kinds of problems.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
