Tom Lane wrote:
> I originally thought that this wouldn't work because the final parsetree
> for the top query would incorporate the other two parsetrees and still
> be too big. But it looks like it doesn't --- when I experimented just
> now, the stored parsetree for a view referencing another view treated
> the sub-view as just a table with no inner structure. I suppose the
> expansion doesn't happen until plan/optimize time.
It happens during rewrite time. The querytree stored for
rules is just the UNrewritten output of the parser. That's
why the rewriter is recursively calling itself with it's own
output.
So splitting up such a huge view into a tree of views (if
possible) is a solution that must not result in a different
final querytree (after applying all view rules). It just
takes a little more time for the rewrite step - but I cannot
estimate how much more.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
