Josh Berkus <josh@agliodbs.com> writes: > The issue here is that the planner is capable of "pushing down" the WHERE > criteria into the first view, but not into the second, "nested" view, and so > postgres materializes the UNIONed data set before perfoming the join.
> Thing is, I seem to recall that this particular issue was something Tom fixed > a while ago. Which is why I wanted to know what version Gaetano is using. It's still true that we can't generate a nestloop-with-inner-indexscan join plan if the inner side is anything more complex than a single table scan. Since that's the only plan that gives you any chance of not scanning the whole partitioned table, it's rather a hindrance :-( It might be possible to fix this by treating the nestloop's join conditions as "push down-able" criteria, instead of the present rather ad hoc method for generating nestloop/indexscan plans. It'd be quite a deal of work though, and I'm concerned about how slow the planner might run if we did do it like that. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]