Re: Join order and access path

>"Jeffrey Lichtman" wrote:

> I wrote the original implementation of the optimizer

Well, jeez, it's so simple and straight forward I hope you were able to find
enough fun and exciting things to fill up all of your free time;-)

Seriously, thanks for offering the explanation. Thanks to Dibyendu many of
the developers are offering their expertise in helping the rest of us come
to grips with the 'database par excellence' known as Derby.

>For example, if you have a five-way join of tables
>t1, t2, t3, t4 and t5, and the current permutation being considered is t3 -
>t1 - t2 (with t3 as the outermost table and t2 as the innermost), it can
>evaluate the join "t3.c1 = t2.c2" at the third position in the join order,
>so when it adds table t2 it pushes the expression down to that level in the
>order. Later, when it removes t2 from the join order to consider some other
>table there, it pulls the expression back out of the join order.

Any chance you could add a paragraph or two and relate this five-way join to
an actual sample query to show just what the permutations might be and the
order that they would be processed? This also might help clarify your use of
'depth first' and 'left deep'.