Sorry for the delay – very busy these days. I don’t have a lot of time to do any detailed investigation on this issue right now but my initial thought is that any operation that can be cut short (such as a nested loop join or a table access by index rowid) would have it’s cardinality modified to N. Operations that are not able to be stopped would not.

Kerry

No problem. =)

The 10053 show that the table cardinality is 10. If you use FIRST_ROWS_N, the 10053 will show that the cardinality changes to match N. This seems to be a problem to me. In fact, I have an open case with Oracle about this issue and found out this morning that it is rooted in unpublished bug 4887636.

My question is, would you expect the 10053 trace to show a cardinality of 10 if you know for a fact that the table does not have 10 rows and the predicates (whether ACCESS or FILTER, or even JOINs for that matter) do not return 10 rows?

I’m not sure I understand your first question. Could you restate it using different words? :)

I think pf probably stands for predicate filter and I think you are correct that it is calculated as K/N.

Kerry

I fear I may have a stupid question, but I’ll ask anyway. In the 10053 trace output for first_rows(10) (above), we see:
—————————————–
BEGIN Single Table Cardinality Estimation
—————————————–
Table: SKEW Alias: A
Card: Original: 10 Rounded: 10 Computed: 10.00 Non Adjusted: 10.00

Is it expected that the estimated cardinality of a table is equal to the optimizer_mode in this case? From what I understand, first_rows is kind of ‘fooling’ the CBO into thinking that a set number of rows may (or may not) be returned, but if first_rows artificially effects the cardinality of a rowsource, it would seem that more query plans would not be optimal. For example, choosing a table with an estimated cardinality of 10 when it really has 10000000 rows to be the inner table of a nested loop join.

I apologize if this was already explain and I missed it.

As a side note, what is “pf”. It looks like it is K/N.

Thanks for your time,

Yes, you are correct. The same plan was generated with or without the hint because the number was much greater than the cardinality (100M row table, first_rows_999999999). I should have saved the 10053 trace file, but no use crying over spilt milk. The quick fix was a profile to force the full table scan (ran in about 1 hour) and a recommendation for the new index on PYMET (which has now worked it’s way through change control).

Kerry

my first thought was when reading the beginning of your post that the hint should be ignored due to the fact that the number of rows specified is very likely larger than the estimated cardinality of the ALL_ROWS mode.

You basically confirmed that, so my question is now: Is the bad execution plan using that index caused by the FIRST_ROWS hint / rownum predicate or not?

I assume that you ought to get the same bad plan when using the ALL_ROWS mode since the optimizer should effectively “ignore” the hint after determining the ALL_ROWS cardinality, but I was just looking for a confirmation – it would be interesting if you get a different execution plan although the hint ought to be “ignored”.

Regards,
Randolf

Oracle related stuff blog:
http://oracle-randolf.blogspot.com/

Co-author of the “OakTable Expert Oracle Practices” book:
http://www.apress.com/book/view/1430226684
http://www.amazon.com/Expert-Oracle-Practices-Database-Administration/dp/1430226684