Re: Terrible plan for join to nested union

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

In response to

Browse pgsql-performance by date

  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