Comments on: Quiz Night

By: double trouble « Oracle Scratchpad

double trouble « Oracle Scratchpad — Tue, 18 May 2010 19:07:51 +0000

[...] Execution plans,Performance,Tuning — Jonathan Lewis @ 7:06 pm UTC May 18,2010 In the latest Quiz Night, I asked how you could make a query more efficient by changing a two table join into a three table [...]

By: Flado

Flado — Tue, 18 May 2010 07:38:26 +0000

Yay!

But the predicate alone doesn’t do it: one must also SELECT and ORDER BY t3 fields instead of t1 fields.

Saluti!
Flado

By: Jonathan Lewis

Jonathan Lewis — Tue, 18 May 2010 07:23:04 +0000

Flado,

Your additional predicate is an exact match for the one that will be appearing on the blog item that I’ll be publishing later on today.

By: Flado

Flado — Mon, 17 May 2010 13:41:07 +0000

Something like this?

select t3. ... -- what used to come from t1 now comes from t3
from    tableA  t1,
        tableB  t2,
        tableA  t3
where
        t1.filter = ...
and     t2.join = t1.join
and     t2.filter = ...
and     t3.rowid = t1.rowid
order by t3. ... -- ditto

Or am I late to the party?

Cheers!
Flado

By: Jonathan Lewis

Jonathan Lewis — Mon, 17 May 2010 07:49:43 +0000

Gary, Well done - you've put your finger on the critical point. I haven't seen Oracle do it yet (but it might be possible in 11.2) but it's perfectly reasonable to write SQL that visits a table using an index-only access path, and then comes back later by rowid to pick up the table data. I published an example of this type of approach about a year ago, but I'll post a much simpler (and less contentious) example as soon as I have a few minutes.

By: Gary

Gary — Sun, 16 May 2010 23:45:44 +0000

My *new improved* thought.
I think the old plan involved a full table scan of tablea hash joined to a full scan from tableb.

I think the new plan involves an index fast full scan on tablea (columns in the t1.join = t2.join) hash joined to a scan from tableb. The results from that join then use a straight ROWID join to get additional data from tablea (eg stuff required for the SELECT but not for the join/where predicates).

The index being full scan would (in this case) be a lot smaller than the table, so the hash join would be more efficient.

Not sure whether that plan could get chosen by the optimizer without the explicit join.

By: Gary

Gary — Sun, 16 May 2010 23:21:53 +0000

Interesting if adding an extra ‘version’ of tablea into the FROM clause doesn’t change the result. tablea must be joined on a primary or unique key (otherwise you’d have, at least, the potential for duplicates in the result set). If tablea had a unique key on ‘colx’ then joining tablea to itself on ‘colx’ would be an implicit ‘colx is not null’ condition. If 99% of tablea entries had a null value for ‘colx’ and an index existed on that column (which it would do for a unique key), then the optimizer could use the index to single out that remaining 1%, which might provide a better optimizer path.

So I can see how an extra join may give a more efficient path. But if that was the situation then I’d expect you to have simply added a ‘colx is not null’ predicate.

By: Jonathan Lewis

Jonathan Lewis — Sat, 15 May 2010 10:47:45 +0000

I'd need something more concrete to go on, but the comment "Depending on the intermediate result set size this may be more efficient." highlights an important principle.

By: Jim

Jim — Sat, 15 May 2010 07:43:54 +0000

TableA is joined twice here – so maybe this will lead to the use of a HASH JOIN instead of any other join implementation.

Depending on the intermediate result set size this may be more efficient.

Another option would be that by joining TableA again, an index might be used which will allow to spare additional sort operations.

Any of those guesses in the right playfield?

cheers,
Jim.

By: Jonathan Lewis

Jonathan Lewis — Fri, 14 May 2010 20:47:52 +0000

Timur,

The principle of turning a two-table into a more efficient three-table is the important bit. I hadn’t applied a great deal of thought to whether I would do it with just one more predicate in the framework about – but I think I can construct an example with just one more.