>
> > > try making a view. from what others have said, views save the query
> > plan
> > > and have usually, at least for me, been _alot_ faster than normal
> > queries.
> >
> > Views don't save query plans. They are parsetree templates in
> > query rewrite rules.
> >
> So, could you explain what counts for the speed increase. Is the parse
> stage really that costly?
BTW: You might want to take a look at the new documentation
of the rule system to understand how views work in detail.
It could only be the parse stage. After the rule system is
through with the query, the parsetree given to the optimizer
is exactly the same as if you typed in the query that
accesses the real tables. Having a view
CREATE VIEW v1 AS SELECT t1.a, t2.b FROM t1, t2
WHERE t1.a = t2.a;
and doing a
SELECT * FROM v1 WHERE a = 'something';
is 100% the same as
SELECT t1.a, t2.b FROM t1, t2
WHERE t1.a = 'something'
AND t1.a = t2.a;
The optimizer will get exactly the same parsetree and will
generate the same plan then. So the timing difference cannot
be in the optimizer or executor.
But it's interesting. I'll do some tests on it and try to
find out whether parsing of complicated WHERE clauses is that
costly that it can be the reason. Seems the rule system is
quicker than the parser :-)
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) #