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