Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1egEqA-0008VD-4E for pgsql-bugs@arkaria.postgresql.org; Mon, 29 Jan 2018 19:11:38 +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 1egEq9-0006xB-1n for pgsql-bugs@arkaria.postgresql.org; Mon, 29 Jan 2018 19:11:37 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1egEq8-0006x1-SF for pgsql-bugs@lists.postgresql.org; Mon, 29 Jan 2018 19:11:36 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1egEq5-0002A2-Uw for pgsql-bugs@postgresql.org; Mon, 29 Jan 2018 19:11:36 +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 w0TJBQEs007426; Mon, 29 Jan 2018 14:11:26 -0500 From: Tom Lane To: Andres Freund cc: Tomas Vondra , "Todd A. Cook" , Thomas Munro , PostgreSQL Bugs Subject: Re: BUG #14932: SELECT DISTINCT val FROM table gets stuck in an infinite loop In-reply-to: <6340.1517251510@sss.pgh.pa.us> References: <219b37b2-d740-d04a-203a-49ae422028f7@blackducksoftware.com> <1773c302-2fb1-749f-8ccc-62b23617c5ac@blackducksoftware.com> <25629.1512580464@sss.pgh.pa.us> <20171206171923.dg7phzfh7nb4lou3@alap3.anarazel.de> <7de4b2d6-b119-7d15-04d8-4c0fcb29cbc3@2ndquadrant.com> <20180126234537.dyu6jwnqz7snpq7n@alap3.anarazel.de> <14184.1517010515@sss.pgh.pa.us> <20180129010213.rt3nu73ilff756f6@alap3.anarazel.de> <5429.1517250335@sss.pgh.pa.us> <20180129183049.xqoejgs52x37xnyr@alap3.anarazel.de> <6340.1517251510@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Mon, 29 Jan 2018 13:45:10 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <7424.1517253086.1@sss.pgh.pa.us> Date: Mon, 29 Jan 2018 14:11:26 -0500 Message-ID: <7425.1517253086@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk One other point here is that it's not really clear to me what a randomly varying IV is supposed to accomplish. Surely we're not intending that it prevents somebody from crafting a data set that causes bad hash performance. If a user with DB access wants to cause a performance problem, there are and always will be plenty of other avenues to making that happen. If the idea is that for a data set that otherwise would have bad hash performance, choosing a different IV would (almost always) fix it, that sounds good but you're ignoring the inverse case: for a data set that works fine, there would be some choices of IV that create a problem where there was none before. I see no reason to think that the probability of the former kind of situation is higher than the latter. So I'm on board with using the extended hash functions when available, but I'm not convinced that a varying IV buys us anything but trouble. regards, tom lane