Klint,
> This is how I interpret it (if anyone wants to set me straight or
> improve on it feel free)
>
> Views are implemented as rules.
>
> Rules are pretty much just a macro to the query builder. When it sees
> the view, it replaces it with the implementation of the view.
Right so far.
>
> When you join a view to a table, it generates a subselect of the
> implementation and joins that to the other table.
More or less. A join set and a subselect are not really different in the
planner.
> So the subselect will generate the entire set of data from the view
> before it can use the join to eliminate rows.
Well, not exactly. That's what's happening in THIS query, but it doesn't
happen in most queries, no matter how many view levels you nest (well, up to
the number FROM_COLLAPSE_LIMIT, anyway).
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.
--
Josh Berkus
Aglio Database Solutions
San Francisco
