Thanks much for sharing that scenario. This is why it is extremely important to have a strategy that worka for you: what works for someone else, may not work for you due to limitations like this. A similar scenario is also true for 11g with the use of incremental stats: they can only be gathered on a partitioned table and would not work in a partition exchange scenario.

regarding the options mentioned how to gather statistics after bulk loading a partition:

“Data is loaded into a staging table, stats are gathered, and the staging table is partition exchanged into the target table.”

I think it could be worth to note that this option has to be checked carefully as it effectively disables the (default) SIZE AUTO feature introduced in 10g. So if you e.g. migrate from 9i to 10g and want to take advantage of the SIZE AUTO feature then the data loading needs to be changed in such a way that the statistics are gathered on the actual table (partition) after exchanging the partition. Otherwise the SIZE AUTO feature will be reduced to SIZE 1 as usually no (or may be even misleading) column usage of the staging table is used to gather the statistics.

I’ve recently posted a note about this along with a test case here: Exchange partition and the SIZE AUTO option of DBMS_STATS

Regards,
Randolf

You are correct. If cascade=>true then index stats are also gathered using the specified estimate_precent. If cascade=>false then only table stats are collected, not index stats.

I am not sure what you mean by “best” (what is your goal?), but when index statistics are gathered as part of a table statistics collection, they are gathered serially, one after another. If you wish to consume more resources to shorten the duration of the collection, you could gather index statistics separately using DBMS_STATS.GATHER_INDEX_STATS in multiple, concurrent database sessions. You can select the granularity that works for you: table at time or index at a time.

When gathering stats with dbms_stats, I think I’m understanding that if cascade=>false, then index stats, for the related tables, will not be gathered. But if cascade=>true, then the estimate_percent listed will also be used for the related indexes. Is this correct?

If so, what is the best way to compute stats on all related indexes for a table… irrelevant of the estimate_percent used?

To be more precise, it is probably not a good idea to use bind variable predicates on columns on which a histogram exists. It is plausible to use histograms in an OLTP system, if the application uses a literal value for that column in the predicate and not a bind value. Perhaps this is where the confusion came in. It is not a global binary “use” or “don’t use”, but rather a “don’t use together for a given column.” Hopefully that adds some clarity. For this reason, I suggested to use REPEAT; for the case where a histogram is desired and the application has been modified to use a literal value. Using “SIZE 1″ would remove the desired histogram on subsequent stats gathers.

From what I have seen, bind peeking in itself does not generally seem to present an issue. I would guess that for the most part an equal or better plan can be chosen using bind peeking. Of course, this discounts the cases when histograms exist. Given this, would you be inclined to blame bind peeking? I personally do not. This is why my position is not to disable bind peeking, but rather control the collection of histograms to avoid the issue that arises from the combination of the two, for a given column.