Comments on: Join Ordering – 1

By: Web Presentation « Oracle Scratchpad

Web Presentation « Oracle Scratchpad — Mon, 05 Mar 2007 23:45:51 +0000

[...] The general structure of the query used was the one I first introduced in the blog item about Join Orders. [...]

By: Jonathan Lewis

Jonathan Lewis — Tue, 06 Feb 2007 19:16:54 +0000

Avanish, I wasn’t specifically focusing on what the optimizer can do as on what the best strategy might be. In this 4-table query, there is a join strategy which Oracle’s optimizer won’t even consider (even though it might be the best one) because it it not a ‘left-deep’ strategy.

I was interested in your comment about the semi-join and the unnesting being different trees. In some tests that I’ve forced onto the optimizer, I got all 24 possible join orders for a query of this type, and some of them included the simple unnesting (in-line view) aproach AND the semi-join approach in the same join order. So I had concluded that there was no ‘separate space’ to distinguish between the two – am I definitely wrong ?

By: Avanish

Avanish — Mon, 05 Feb 2007 11:43:27 +0000

JL, I think if both the subqs are un-nested then we have 4! possible methods. If the subqs are not un-nested then, we have 2! and then the evaluation of the subq. Also if the rules for semi-join applies, then that is another tree.

On the whole, it depends on new initial join orders also.

So unless we get a 10053 dump, i dont think we can give a number.

by the way, apologies for using JL!!!!!!!!!!!!!!!

By: Mikito Harakiri

Mikito Harakiri — Wed, 24 Jan 2007 18:51:05 +0000

Or yeah, that was a typo.

By: Mikito Harakiri

Mikito Harakiri — Wed, 24 Jan 2007 18:50:14 +0000

Catalan(3) = 5, which is a coincidence.

By: Wolfgang Breitling

Wolfgang Breitling — Wed, 24 Jan 2007 18:47:16 +0000

Mikito, what am I missing? Isn’t 5*4! the same as 5! (= 1*2*3*4*5)? Or was that a typo and you meant “there are 5*4! plans but the optimizer looks into only 4! of them”

By: Mikito Harakiri

Mikito Harakiri — Wed, 24 Jan 2007 17:41:11 +0000

That’s right, how the supposed answer 14 can be less than 4! ? Therefore, for unnested and merged plans there are 5*4! plans but the optimizer looks into only 5! of them. Some plans which are not unnested, howewer, are equivalent to bushy plans — this is one of the reason why unnesting&merging can potentially miss a good plan.

By: Jonathan Lewis

Jonathan Lewis — Wed, 24 Jan 2007 10:58:22 +0000

Mikito, I was planning to be rather more informal; however, since you’ve mentioned Catalan numbers, why isn’t the starting value (Catalan(3) * 4!). Catalan(3) as the number of arrangements of a tree with 4 “leaf points”, and 4! as the possible permutations of the tables around the “leaf points”. Am I missing something like a commutativity assumption that changes the formula ?

Antonio – there shouldn’t be any performance difference.

By: Antonio

Antonio — Wed, 24 Jan 2007 08:13:38 +0000

@Jonathan

A question on the exists sub-query.

In the sub-query, you write something like “select column”, I’m used to write something like “select *”.

I saw other forms: “select 1″ and even “select NULL” (this one in Oracle documentation).

Are there any performance difference?

Thank you.

By: Mikito Harakiri

Mikito Harakiri — Wed, 24 Jan 2007 03:30:42 +0000

Assuming that all the subqueries are unnested, and that tuple iteration execution semantics is not really different from nested loop, we should have 14 different executions (4th Catalan number). So the answer is 14 minus the number of join orders appearing in the 10053 trace.