On Tue, Feb 28, 2017 at 11:16 PM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
