Re: BUG #14932: SELECT DISTINCT val FROM table gets stuck in an infinite loop
От | Tom Lane |
---|---|
Тема | Re: BUG #14932: SELECT DISTINCT val FROM table gets stuck in an infinite loop |
Дата | |
Msg-id | 14238.1517266482@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #14932: SELECT DISTINCT val FROM table gets stuck in aninfinite loop (Greg Stark <stark@mit.edu>) |
Ответы |
Re: BUG #14932: SELECT DISTINCT val FROM table gets stuck in aninfinite loop
|
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: