Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eMdHG-0004oV-4H for pgsql-bugs@arkaria.postgresql.org; Wed, 06 Dec 2017 17:14:34 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eMdHF-0008BN-HH for pgsql-bugs@arkaria.postgresql.org; Wed, 06 Dec 2017 17:14:33 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eMdHF-0008B7-8O for pgsql-bugs@lists.postgresql.org; Wed, 06 Dec 2017 17:14:33 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1eMdHC-0003CG-Nu for pgsql-bugs@postgresql.org; Wed, 06 Dec 2017 17:14:32 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id vB6HEOXB025630; Wed, 6 Dec 2017 12:14:24 -0500 From: Tom Lane To: "Todd A. Cook" cc: Tomas Vondra , Thomas Munro , Andres Freund , PostgreSQL Bugs Subject: Re: BUG #14932: SELECT DISTINCT val FROM table gets stuck in an infinite loop In-reply-to: <1773c302-2fb1-749f-8ccc-62b23617c5ac@blackducksoftware.com> References: <20171127185700.1470.20362@wrigleys.postgresql.org> <7a22f496-92b5-d199-984e-183965918304@blackducksoftware.com> <20171127221041.mezzysc4zcfsqkyc@alap3.anarazel.de> <17357.1511841783@sss.pgh.pa.us> <9cd29b81-7ba1-91a2-f491-9014f4ac87e6@blackducksoftware.com> <2a76784c-06cb-46ec-35be-9895d144b839@2ndquadrant.com> <219b37b2-d740-d04a-203a-49ae422028f7@blackducksoftware.com> <1773c302-2fb1-749f-8ccc-62b23617c5ac@blackducksoftware.com> Comments: In-reply-to "Todd A. Cook" message dated "Wed, 06 Dec 2017 11:58:04 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25628.1512580464.1@sss.pgh.pa.us> Date: Wed, 06 Dec 2017 12:14:24 -0500 Message-ID: <25629.1512580464@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk "Todd A. Cook" writes: > If hashint8() is ultimately invoked by TupleHashTableHash() in execGroups.c, > it might be magnifying the difficulties here. The least significant bits, > which are used as the bucket number in simplehash.h, are not very well > distributed: > select val, to_hex(val), to_hex(hashint8(val)) from temp_f_03 limit 15 ; > val | to_hex | to_hex > ----------------------+------------------+---------- > 4444319256653758784 | 3dad64d121468140 | 805ffffe > 554179993563924608 | 7b0d7c49a018880 | 84dffffb > -3383965646518123872 | d109bd2c6b2982a0 | 9c3ffff7 > -4706811054739454944 | beae0c48915f8420 | 191ffff6 > 618200668902031424 | 8944a3ba5d08040 | 2a3ffff0 > 5074043922812601024 | 466aa01079f982c0 | 7effffee > -8783188184262212928 | 861bd8e1b9a482c0 | a6bfffea > -4597800992953433792 | c031545b6b128140 | b1dfffea > 8563040839807173408 | 76d608465dde8320 | 7d9fffe6 > 6092569112843158816 | 548d27540c888520 | 6f9fffe6 > -7313351060369079936 | 9a81c1f558f98180 | 68ffffe5 > -1786712428165627488 | e7345283536981a0 | 73ffffe5 > -6153596242570280896 | aa9a08d20e6b8040 | ac3fffd8 > 88426174078092128 | 13a272306c58360 | b57fffd8 > -5305589938458295680 | b65ec20faa4e8280 | ba9fffd3 Checking out hashint8() on random data shows no such obvious fault. You've apparently got a data set that exposes a weakness in hashint8, but it's not very clear what that is. In any case, the hashtable code needs to not fall over in the presence of a lot of collisions, regardless of the exact reason for there being a lot. regards, tom lane