Re: [SQL] Joining bug????

>
> > > 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) #