Graham , left deep and bushy – I’ll try to write up a note about that some time soon. [Update: now done.] Roughly speaking left-deep is what the optimizer tree looks like when a query has a single from clause with list of tables; bushy is what you get if you force Oracle to generate intermediate results.

Noons, I think the only way an outsider could find out is to generate lots of scenarios with, and without, the first_rows hint, then compare the 10053 trace files to see what calculations were omitted when first_rows is invoked. Generating a complete set of scenarios is, of course, the tricky bit.

Amit, the use_hash(tabX) hint tells the optimizer to use a hash join to join this table to the preceding result set. It doesn’t dictate the order at all. The swap_join_inputs(tabX) forces tabX to be the build (first) table in the join, the 10g hint no_swap_join_inputs(tabX) forces tabX to be the probe (second) table.

Sokrates - If I’ve read your syntax correctly this won’t get all the hints, just the ones that happen to be used in the embedded SQL – and there are far more than that. I used to use strings on the binaries then search the text by hand for an “obvious” hint such as star_transformation, then check any text around it. This doesn’t work in 10g as the hints are now just reserved words, and don’t end up grouped together in the binary. [Update June 2009: In 11g you have the view v$sql_hint, listing the hints, the version they appeared in, and the version they got into stored outlines.]

David - I’m fairly sure that the constant change in the optimizer means that some outlines won’t work as expected after an upgrade. I haven’t actually tested this, but I have a few easy examples that could demonstrate the principle and I will get around to testing them one day. However, it is possible that outlines are more stable than “ordinary” end-user hints, as there is some information in the outline tables (especially in 9i) that is not available through normal hints, and this may be enough to keep the outlines on track.

RobH - “terrified” is a fairly good approach, though possibly just a little over the top. Hints are NOT a good thing in production for the reaons I gave in an earlier article. I always advise people to minimise their use of hints, document the cases properly, and check each one carefully on any upgrade.

“there is no “right join order””

Came on! :)

I mean the “one that make your query fast”.

I didn’t mean something like “left outer join” nor right nor full…

I was talking about join T1 to T2 using a NL or T3 to T1 using hash…
Hope it’s a bit more clear now.

“why is software complexity growing ?”

Only as an excuse for having more and more hints! ;-)

The optimizer gets “smarter” at any new Oracle release and having more hints it’s like having more way to tweak the engine.
It’s as good or bad as you good or bad your Oracle is configured, your statistics are gathered and so on…

More and more I keep thinking to Oracle patterns…

Bye! :-)

strings `which oracle`|grep “\/\*\+” | grep “\*\/” | sed ‘s/\*\/.*//’ | sed ‘s/.*\/\*\+//’ | tr ‘ ‘ ‘\n’ | dd conv=ucase | sort -u

contatin a complete list of all (documented and undocumented) Hints ?

“Why are hints growing?”

why is software complexity growing ?

“I’m thinking if the ANSI join syntax can really help (Oracle or us?) selecting the right join order.”

what do you mean by “the right” ?

there is no “right join order”

I tried to combine the 10132 trace (that shows hints in ‘outline data’ section) with the 10g dbms_sql_tune task that parses all possible execution plans for a query.

So I have the trace with all possible execution plans and their outline information.
It can give an idea of the hints required to have the desired execution plan, but outline data gives something like:

  /*+
    BEGIN_OUTLINE_DATA
      IGNORE_OPTIM_EMBEDDED_HINTS
      OPTIMIZER_FEATURES_ENABLE('10.2.0.1' )
      ALL_ROWS
      OUTLINE_LEAF(@"SEL$58A6D7F6" )
      MERGE(@"SEL$1" )
      OUTLINE(@"SEL$2" ) 
      OUTLINE(@"SEL$1" )
      INDEX(@"SEL$58A6D7F6" "E"@"SEL$1" "IDX$$_07E70001" )
      INDEX(@"SEL$58A6D7F6" "D"@"SEL$1" ("DEPT"."DEPTNO" ))
      LEADING(@"SEL$58A6D7F6" "E"@"SEL$1" "D"@"SEL$1" )
      USE_NL(@"SEL$58A6D7F6" "D"@"SEL$1" )
    END_OUTLINE_DATA
  */

and I had to translate it to the following hints: /*+ INDEX(E PK_EMP) INDEX (D (DEPT.DEPTNO)) LEADING (E D) USE_NL(D) */

But I have no idea what means “IDX$$_07E70001″ – and, by the way, I didn’t know about the INDEX( ()) syntax
Maybe you have more information about it.

I think this can help having ‘full hinting’ for a query.

Regards,
Franck.

Does that mean that use_hash(t) means that “use t as the probe table” in the hash join ?