From: | Nate Allan <nallan(at)ancestry(dot)com> |
---|---|
To: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Terrible plan for join to nested union |
Date: | 2012-07-09 06:20:41 |
Message-ID: | 9B2D6747F4AB8A47BE45216B06DEDAF92ABE6791@PREXMB01.myfamily.int |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
>Right now, UNION DISTINCT, along with INTERSECT and EXCEPT, have basically no optimization support whatsoever...
> Sorry to be the bearer of bad news, but this isn't going to change just because you try to label it a bug.
Given the medium, I'll try not to read that in a snarky tone, after all, surely it's not unreasonable to label it a defect for a system not to optimize one of the basic relational primitives. That said, I know well the annoyance when a user cries bug when the system is working as-designed. In any case, I'm at least glad to have resolution; I know that there is no choice but to work around it.
For a maximally general work-around given that the union is the essence of a reused view, perhaps a reasonable approach is to switch to Union All and nest it within a Distinct outer query. That seems to produce workable plans in my tests so far. Maybe that could even form the basis of a planner enhancement that wouldn't require a complete refactor.
Thanks again,
-Nate
From | Date | Subject | |
---|---|---|---|
Next Message | Sylvain CAILLET | 2012-07-09 06:49:36 | Re: Create tables performance |
Previous Message | Tom Lane | 2012-07-09 05:49:52 | Re: Terrible plan for join to nested union |