Timeline for Slow postgres query that uses quick sort instead of hash-aggregate
Current License: CC BY-SA 3.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 14, 2017 at 21:08 | comment | added | maxTrialfire | After looking into this I can say with confidence that the estimate vs actual row count mentioned above is a red herring. It looks as though that's how it shows append operation and the above is the product of the union all view | |
| Mar 14, 2017 at 15:35 | comment | added | maxTrialfire | With regard to joining alias twice: It is necessary because alias is an intermediary table between event_page.person_alias and session.person_alias. It's not enough to simply join on session_id. This is simply a biproduct of how data is collected and stored and I have to live with it. | |
| Mar 14, 2017 at 15:32 | comment | added | maxTrialfire |
Thanks Evan. So let's start with the Hash Join estimate you mentioned. 11M vs 2 is quite the discrepancy, however - the second query plan link shows a similar issue Hash Join (cost=211,345.82..393,431.24 rows=1 width=32) (actual time=1,883.910..4,126.021 rows=801,151 loops=1) Hash Cond: (((s.person_alias)::text = (a1.alias)::text) AND (a.person_id = a1.person_id)) see line 3 of the second explain link.
|
|
| Mar 14, 2017 at 7:27 | history | answered | Evan Carroll | CC BY-SA 3.0 |