| From: | "Todd A(dot) Cook" <tcook(at)blackducksoftware(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | 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:47:23 |
| Message-ID: | 71fd9e22-0a24-843c-fbd3-66461a08864c@blackducksoftware.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On 01/30/18 14:34, Andres Freund wrote:
> 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...
Hmmm, that's intriguing; I'll look into it. Thanks! :)
-- todd
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2018-01-30 22:07:20 | Re: pg_hba_file_rules: "scram-sha256" instead of "scram-sha-256" |
| Previous Message | Andres Freund | 2018-01-30 19:34:53 | Re: BUG #14932: SELECT DISTINCT val FROM table gets stuck in an infinite loop |