Thanks for the comments.

I totally agree that your paraphrase of what the index hint is saying is more accurate than mine. (too bad they don’t document hints better, and that they don’t have the option to raise a warning when they are ignored).

I also agree that the INDEX_RS(_ASC/DSC) hints are more specific and therefore a better choice when trying to force a specific plan. Unfortunately, there are some problems (i.e. bug) that cause Oracle to create an invalid hint. In the particular case I showed (2nd batch of code), the other_xml field contains the hint

INDEX_RS_ASC(@”SEL$1″ “A”@”SEL$1″ (”SKEW”.”COL2″ “SKEW”.”COL1″))

- even though the actual plan does an

INDEX FULL SCAN

Therefore, creating an Outline on this statement changes the plan. In this case, changing the hint to the more generic INDEX(xxx), allows the optimizer to use an INDEX FULL SCAN. By the way, 11.2 works around this bug by doing exactly that, changing the INDEX_RS_ASC to INDEX. So I am agreeing with you on this point as well, more specific is certainly better (unless of course it doesn’t work, like in this corner case).

I’m not much of a fan of the new index format though. I understand your point about changing indexes and in general it makes sense. With respect to Outlines/Profiles/Baselines though it seems too flexible at times. By that I mean that occasionally an Outline or Profile will not keep a plan from changing - and sometimes it’s due to this non-specific Index Hint format. I think one of the reasons is that the Outline Hint created by Oracle (again pulled from the other_xml field) specifies every column contained in the index. That is to say that if a plan uses an index that contains 10 columns, all ten will be listed in the hint, regardless of the fact that only a couple of them may actually be used in the statement. You can see this in the example in the post as well. The SKEW_COL2_COL1 index has COL2 and COL1. So the hints specifies both columns, even though the SQL only references COL1. I guess it just seems more straight forward and less error prone to actually specify the index name (although I acknowledge that it may go bad at some point in the future if someone changes the indexes).

Thanks again for your comments.

Note: I’ll have to do a little verification (and refreshing my memory) before I respond to your comments on
Why Isn’t Oracle Using My Outline / Profile / Baseline.

Kerry

Regarding this comment:

INDEX(TABLE_NAME.COLUMN_NAME TABLE.NAME.COLUMN_NAME …)
Translation: If possible, use any available index on any of these columns.

I think the translation should be more like:

“Use the index on this set of columns in this order but if the required index doesn’t exist then use the cheapest index that starts with this set of columns in this order.”

Personally I think it’s a better way of hinting an index than the old “index(alias index_name)” method given that (a) people sometimes rename indexes to conform to naming conventions and (b) people sometimes drop one index because it starts the same way as another. In both cases, the new mechanism is likely to reduce the risk of damage.

The “index_rs(_asc/_desc)” hints were introduced, by the way, because an index() hint could allow the optimizer to choose between a range scan and a full scan - and that meant that a hinted query could still change its execution path dramatically unless all the other hints had been carefully set up to avoid the error - so I wouldn’t be too keen to change a index range scan hint to a simple index hint.

Regards
Jonathan Lewis