From: Tom Lane <tgl@sss.pgh.pa.us>
To: Greg Stark <stark@mit.edu>
cc: Andres Freund <andres@anarazel.de>,
        Tomas Vondra <tomas.vondra@2ndquadrant.com>,
        "Todd A. Cook" <tcook@blackducksoftware.com>,
        Thomas Munro <thomas.munro@enterprisedb.com>,
        PostgreSQL Bugs <pgsql-bugs@postgresql.org>
Subject: Re: BUG #14932: SELECT DISTINCT val FROM table gets stuck in an
 infinite loop
In-reply-to: 
 <CAM-w4HO4ur37XMqpYPardPa3rZiDVcSYfe62sPAfTGooDFk3WQ@mail.gmail.com>
References: <219b37b2-d740-d04a-203a-49ae422028f7@blackducksoftware.com>
 <c15378b3-d4aa-a5c0-5538-dd52904dcbc6@2ndquadrant.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> <7425.1517253086@sss.pgh.pa.us>
 <CAM-w4HO4ur37XMqpYPardPa3rZiDVcSYfe62sPAfTGooDFk3WQ@mail.gmail.com>
Comments: In-reply-to Greg Stark <stark@mit.edu>
	message dated "Mon, 29 Jan 2018 22:16:24 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <14237.1517266482.1@sss.pgh.pa.us>
Date: Mon, 29 Jan 2018 17:54:42 -0500
Message-ID: <14238.1517266482@sss.pgh.pa.us>
Precedence: bulk

Greg Stark <stark@mit.edu> writes:
> On 29 January 2018 at 19:11, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.

> I actually think that is a real live issue that we will be forced to
> deal with one day. And I think that day is coming soon.

> It's not hard to imagine a user of a web site intentionally naming
> their objects such that they all hash to the same value. Probably most
> systems the worst case is a query that takes a few seconds or even
> tens of seconds but if you get lucky you could run a server out of
> memory.

By their very nature, hash algorithms have weak spots.  Pretending that
they do not, or that you can 100% remove them, is a fool's errand.

You could always "set enable_hashjoin = off", and deal with mergejoin's
weak spots instead; but that just requires a different data set to
expose its performance shortcomings ...

			regards, tom lane