| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | "Todd A(dot) Cook" <tcook(at)blackducksoftware(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: BUG #14932: SELECT DISTINCT val FROM table gets stuck in an infinite loop |
| Date: | 2018-01-30 19:34:53 |
| Message-ID: | 20180130193453.gprzxco2almo5lpk@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On 2018-01-30 13:57:44 -0500, Todd A. Cook wrote:
> Out of curiosity, I then modified hashint8() as previously described.
> With that change, run time dropped to 11 minutes (also average of 3
> runs).
>
> FWIW, the data values in these sets are sort-of random (where I can't
> explain the "sort-of" in a public forum), but strongly biased towards
> negative infinity. Starting again from scratch, we could probably remove
> the bias, but we have 28-30 billion of these things collected over the
> last 14 years (starting in PostgreSQL 7.4) and it's kinda tough to change
> directions at this point...
FWIW, you could just create a different hash opclass and use it for
those queries...
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Todd A. Cook | 2018-01-30 19:47:23 | Re: BUG #14932: SELECT DISTINCT val FROM table gets stuck in an infinite loop |
| Previous Message | Todd A. Cook | 2018-01-30 18:57:44 | Re: BUG #14932: SELECT DISTINCT val FROM table gets stuck in an infinite loop |