Vadim wrote:
>
> Jan Wieck wrote:
> >
> > If we put any view into a subquery RTE, we force the planner
> > to materialize the view and do a nestloop over t3 and
> ^^^^^^^^^^^
> Do you mean creating some tmp table etc?
> No - it's not required.
Sometimes a sortset is required (grouping, nesting etc.).
With materialize I meant the same thing the executor does for
a scan, merge or iter node. They return in memory tuples from
a relation or a temp file. In our new case it's mostly the
same as a scan node that does the view selection inside. And
it returs the same tuples as a SELECT * from the view would.
That's internal, on the fly materialization of the view.
> On the other hand, as we talk about query optimization - why
> rule system should do optimizer' work? Why not just put
> _any_ VIEW' query into FROM and let optimizer decide
> could query be rewritten as join or not? Ppl do strange
> things sometimes -:) Sometimes they use subqueries in
> WHERE while joins could be used and our optimizer don't
> try to catch this. I know that Sybase does.
> And, imho, we should implement this ... sometime -:))
Depends on where the optimization is done. If we do it on the
parsetree (Query struct), it's the job of the rule system.
The optimizer does not have to modify the parsetree. If it is
done on the way from the parsetree to the plan, it is the job
of the optimizer.
If it is possible to do it on the parsetree, I would do it
there.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
