Nate Allan <nallan@xxxxxxxxxxxx> writes: > It seems to me that the join condition (and hence the restriction) should be pushed down into both sides of the union to bring the cardinality limit from millions to 1. I'm imagining a rewrite like this: > R(a) J (b U c) -> (b J R(a)) U (c J R(a)) > ...where R = Restrict, J = Join, U = Union [ eyes that suspiciously ... ] I'm not convinced that such a transformation is either correct in general (you seem to be assuming at least that A's join column is unique, and what is the UNION operator supposed to do with A's other columns?) or likely to lead to a performance improvement in general. We possibly could push down a join condition on the inner side of a nestloop, similarly to what's done in the UNION ALL case ... but that would require a complete refactoring of what the planner does with UNIONs. By and large, very little optimization effort has been put into non-ALL UNION (or INTERSECT or EXCEPT). You should not expect that to change on a time scale of less than years. regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
