I too find this to be the correct strategy for applying histograms to a system – start with none and look whether there are system parts that need some. Is it a general approach you advise your customers? Or was there any specific bit of information (e.g. using literals in the predicates) that made you think this would make the system perform better?

I am a little surprised by your comment that: “Oracle never adds any additional cost for user-defined PL/SQL functions”, since my example seems to show quite clearly that Oracle has added a cost in this case.

Do you have a simple demonstration that I can use to recreate your observation – and have you tested it on the latest version of Oracle ?

Looking through my notes I find that I haven’t done anything with “associate statistics” since 2006, so I’m not in a position to make any comments about what that might do, and I haven’t come across but 12332294 before. You question did make me wonder, though, whether your comment about “no cost” applied to operators rather than functions.

Sorry about the delay answering – I’ve done 3 US, two conferences, and two seminars in the week.
The core of the change occurred in 10g with cost-based query transformation.

I have found that Oracle never adds any additional cost for user-defined PL/SQL functions and this can lead to really sub-optimal plans because a condition like “myfunction( mColumn ) = 0″ always has a default selectivity of 5% and an additional cost of 0, even if it involves complex subqueries .
Did you try to use ASSOCIATE STATISTICS to inform the CBO of the true cost of the function, or do you think that bugs like 12332294 make the “ASSOCIATE STATISTICS ” command useless?

Regards,
Andrea

Did this change with Oracle 11 ?

Thanks for the compliment.

Your comment is very useful – it’s very easy to overlook a critical detail when trying to work out why an execution plan is so bad and your suggestion that “index full scan” and a missing “sort order by” is an excellent candidate for being on a “quick check” list before you start doing anything complex to analyze the problem. It’s also an important indication of how important it is to get a current execution plan from memory rather than relying on “explain plan”.

Part of the analysis I haven’t shown is the “Outline” content for this plan. This would show any local settings for optimizer parameters as opt_param() hints, but also show things like optimizer_features_enable() and (most importantly from your perspective) any hints like first_rows(1).

Just one supplementary question: when I see the presence of INDEX FULL SCAN coupled with the absence of a SORT OPRDER BY operation (while the query contains an ORDER BY) I immediately think about the optimizer being in a FIRST_ROWS mode. Although I don’t see in the query what could make the CBO jumping to a FIRST_ROWS mode, have you investigated this option before?

That would have been tough.
I think in this particular case, and with this particular hint, there’s a fairly good chance we would have been safe. The /*+ no_push_subq */ hint falls into the class that I call “strategic” hints – it’s not what I call micro-management, and that tends to make it a safer hint to use in these circumstances. (I’d be very unhappy about using a hint like “index(tableX, indexY)” because of the high probability that Oracle would use different join orders in different uses of the view – then use the index as directed with catastrophic results.)

Historically the optimizer always used to leave subqueries to the last possible moment in an execution plan, so giving it an explicit hint to do so is something was fairly likely to recreate the pre-upgrade execution plan, and fairly likely to do “not much” damage if it wasn’t the ideal solution in every case.

You’re right to raise the point though.

In this case we could have been in serious trouble if dropping the histograms hadn’t worked. If the application had been using bind variables in all the appropriate places we could have generated an SQL Plan baseline for this query – but it was using literals, and there’s no way (at present) to “force match” a baseline to a query in the way that you can with profiles. (Possibly we could have used Kerry’s mechanism for cheating and forcing a complete sets of hints into the system as a “force match” profile – but I wouldn’t want to do that on a production system).

We could have investigated the effect of setting the optimizer_mode back to the earlier version to see how many things got fixed and how many new things broke. We might have tried running with cursor_sharing = force so that we could use attach an SQL Plan baseline to the query with bind variable substitution.

We might simply have got lucky and found that this particular view had been created for this particular piece of front-end code – but we would certainly have had to search the entire applicatin for every references to the view and tested for side effects.

” we would have been able to work around the problem because the vendor embedded most of the code complexity in views – so we could add hints to the view definitions ”

I think I’d be a bit worried that the hinted view might well make *this* bit of generated code run well (or at least for problem values) but that the view might be in use in multiple places with different semantics and that a hint that benefited us here would be detrimental elsewhere. I wonder how you might triage this potential side effect?