Josh Berkus <> 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]

Reply via email to