Dynamic sampling is not used when a statement contains bind values, only when the statement contains literals. This would explain why it makes no difference with ACS. OTN has a discussion that might be worth reading: http://forums.oracle.com/forums/thread.jspa?threadID=927493&tstart=-1

I understand that if a new value for a bind variable leads to degraded performance, ACS will (after the second run) lead to a new child cursor and potentially new execution plan. A better plan would be possible only with a histogram present.

I was wondering about dynamic sampling. A new bind value will still degrade performance, which can lead to a new parse/plan via ACS. Even with no histograms (no stats) dynamic sampling could yield a new plan as the skew can be determined. My initial tests show this doesn’t happen and dynamic sampling doesn’t yield a new plan, even with skewed data, using ACS. Testing is still incomplete.

The reason that histograms were gathered in the “Take 2″ version and not in the first collection is that sys.col_usage$ has been populated because I ran 3 queries against the table T1. In the first collection, no queries had been run against T1 so it was impossible for “size auto” to collect any histograms as sys.col_usage$ contained no rows for T1. This is something to be very mindful of; if you are using the default method_opt, the predicates in the queries executed against the tables can trigger new histograms to be collected.

You can use this query to look at sys.col_usage$

select	oo.name owner,
	o.name table_name,
	c.name column_name,
	u.equality_preds,
	u.equijoin_preds,
	u.nonequijoin_preds,
	u.range_preds,
	u.like_preds,
	u.null_preds,
	u.timestamp
from	sys.col_usage$ u,
	sys.obj$ o,
	sys.user$ oo,
	sys.col$ c
where	o.obj#   = u.obj#
and	oo.user# = o.owner#
and	c.obj#   = u.obj#
and	c.col#   = u.intcol#;

If there are no histograms then Adaptive Cursor Sharing will not really change anything. Adaptive Cursor Sharing was designed for the situation where you have a statement with bind variables and histograms exist on the table. Adaptive Cursor Sharing is designed to give a new child cursor and plan if the combination of the histogram and peeked predicate value would give a new plan had it been a literal value.

What’s up with that?

I was looking at Adaptive Cursor Sharing with Dynamic Sampling and was wondering if having method_opt automatically detect skew might be related to dynamic sampling detecting skew, which might affect ACS (when I had no histograms with the default method_opt, dynamic sampling (level 4) didn’t take advantage of ACS).

You should recognize the examples are not about full table scan or not. They are about getting accurate cardinality estimates. I prefer to have a histogram on a skewed column regardless if it participates in an index or not. See, indexes are used as a access method, not a way to calculate cardinality (other than a couple exceptions).

There are many, many data warehouses that run queries against tables with million or billions of rows without indexes on the predicate columns and possibly many of those unindexed columns have histograms if skew is present. Recognize this discussion is not about gathering histograms (or not) on columns which are indexed. It is about gathering column statistics for columns that do not participate in indexes. Not to be too critical, but 10g has been out for over 5 years now, and 11g for over 1 year, so I’m not sure the weight a pre-10g argument contains these days, especially when issues have been fixed.

If you would be so kind as to cite what Metalink notes make such suggestions, it would be appreciated.

So I have this query which was taking a long time to complete according to developers and I put the hint to do a FTS and it completes in 22 minutes as opposed to 2.5 hrs. I want to remove the hint and tune it the right way and was thinking about creating histograms based on the skewness.

With the information provided thus far, I’m not convinced that a histogram is the solution as I am unclear where the problem specifically lies. Do you have evidence that a predicate column (join or filter) has significant skew and the cardinality estimate is too low in this case? Have you simplified this down to a specific table and column? If not, that is ok, but we’ll need to get there to correctly solve this issue.