Comments on: Cardinality feedback

By: Vivek Sharma

Vivek Sharma — Tue, 14 Sep 2010 16:55:27 +0000

On the comment on EGOR above, 11g provides “Cardinality Feedback used for this statement” and changes the plan dynamically. I have noticed this at one of my customer site and plan to write on this. The plan changed for good, in my case, after few executions. This can be controlled by _optimizer_use_feedback.

Regards
Vivek

By: Only Four Left… » Recently relevant (to me) links

Only Four Left… » Recently relevant (to me) links — Mon, 21 Jun 2010 22:16:29 +0000

[...] Lewis' review of a Collaborate '09 presentation on tuning by cardinality feedback, and the slides from that presentation, helped me refresh my approach to a report tuning [...]

By: Egor

Egor — Thu, 21 May 2009 06:24:50 +0000

Gary,
Yes, and it looks like a trend, but it’s still very limited.

By: Gary

Gary — Wed, 20 May 2009 22:39:32 +0000

Egor,
Isn’t that what adaptive cursor sharing in 11g is about – alebit limited to circumstances where there may be skew relating to bind variables ?

By: Randolf Geist

Randolf Geist — Wed, 20 May 2009 09:21:23 +0000

Jonathan,

I just wanted to point out that in cases where you have statements that take simply too long to complete for a full analysis e.g. using DBMS_XPLAN.DISPLAY_CURSOR, it still can be useful to run them with row source statistics enabled, because (at least in recent releases, e.g. 10.2.0.4) the row source statistics get refreshed even when canceling the execution after a while.

So using e.g. DBMS_XPLAN.DISPLAY_CURSOR on that incomplete execution reveals the part of the execution plan where the time was spent so far and allows to pinpoint any discrepancies in estimates and actual row source statistics without having to wait for the completion of the statement.

I guess this should have worked with Michelle’s particular example, too.

Regards,
Randolf

By: Egor

Egor — Wed, 20 May 2009 07:49:54 +0000

Hi Jonathan,
Okay, we can compare E-rows and A-rows to find out where the problem lies. Wouldn’t it be nice if Oracle could do this itself? After completing a query it can (theoretically) compare predicted and actual numbers and “fine-tune” statistics (probably new types of statistics) to reflect the difference. And the query will run faster next time, automagically.
Too fantastic? What do you think about it?

By: Timur Akhmadeev

Timur Akhmadeev — Thu, 14 May 2009 17:08:23 +0000

John, Oracle can use DISTINCT_KEYS of an index for some cases to get more precise cardinality estimation in 10.2.0.4 (with additional setting). See this topic for details.

By: Jonathan Lewis

Jonathan Lewis — Thu, 14 May 2009 08:50:05 +0000

James,

Correct – the “multi-column” variant of 11g’s extended statistics would probably have worked in this case.

We might have to be a little careful, though, as we can’t be certain whether or not the number of distinct combinations was less than 255 – which would dictate whether we wanted to create a frequency histogram, or simply rely on the number of distinct combination.

By: James Park

James Park — Thu, 14 May 2009 03:00:48 +0000

In 11g, isn’t this also a candidate for extended statistics on a virtual column, as described in http://orainternals.wordpress.com/2008/12/19/correlation-nocorrelation-and-extended-stats/ ?

By: Jonathan Lewis

Jonathan Lewis — Wed, 13 May 2009 19:18:34 +0000

John,

That is another possible strategy and, given how small the critical table, it’s a good one to consider.

Just to emphasise your point – the intention is NOT to change a full tablescan into an indexed access path by creating an index, the intention is to tell the optimizer about the number of combinations available in the distinct_keys statistic of the index.

Depending on the version of Oracle, and the uniqueness of the index, the distinct_keys statistic can be used in various ways by the optimizer.