pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Greg Stark <stark@mit.edu>
Cc: Andres Freund <andres@anarazel.de>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Todd A. Cook <tcook@blackducksoftware.com>
Cc: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: PostgreSQL Bugs <pgsql-bugs@postgresql.org>
Subject: Re: BUG #14932: SELECT DISTINCT val FROM table gets stuck in an infinite loop
Date: Mon, 29 Jan 2018 17:54:42 -0500
Message-ID: <14238.1517266482@sss.pgh.pa.us> (raw)
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>

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




view thread (70+ messages)  latest in thread

Message-ID: <14238.1517266482@sss.pgh.pa.us>
Permalink:  ../14238.1517266482@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/14238.1517266482@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: tgl@sss.pgh.pa.us, stark@mit.edu, andres@anarazel.de, tomas.vondra@2ndquadrant.com, tcook@blackducksoftware.com, thomas.munro@enterprisedb.com
  Subject: Re: BUG #14932: SELECT DISTINCT val FROM table gets stuck in an infinite loop
  In-Reply-To: <14238.1517266482@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox