Re: [SQL] Good Optimization

>     There is a simple way to optimize SQL queries involving joins to
> PostgreSQL that I think should be handled by Postgre?  If one is joining
> a tables a,b on attribute "x" and if one has something like x=3 then it
> helps A LOT to say: a.x=3 and b.x=3 in addition to saying a.x=b.x ...
> The example below shoulds the radical speed gain of doing this, and I
> think it isn't something real obvious to most people...
>
>     Of course it could just be a common thing to do in SQL, anyway, just
> thought I'd let you all know what I discovered.
>
>
>
> Here is an example:
> [...]

Hmmmmm,

    wouldn't   it   be  nice  to  do  such  things  automagically
    (rewriter? planner?).

    Even if I don't think that it is that  trivial  as  it  might
    look  like.  The  entire  queries  qualification  is  ONE big
    expression of cascaded  AND  and  OR  nodes.  Deciding  which
    constant  expressions  could  be added again with substituted
    Var nodes because there's  some  "VarX  ==  VarY"  and  don't
    falling into recursion traps isn't easy.

    But  no expression comparing two Var's of different RTE's can
    be put down into an  execution  subtree.  And  that  is  what
    reduces  the  amount  of  data to get joined. I think this is
    worth the efford.

    I think the best place for it will  be  at  the  top  of  the
    optimizer.    It's   more   an  optimization  issue  even  if
    implemented in rewriting technique.


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