If you do a size nnn then that is exactly what gather_stats will do. It could be fewer buckets if there are fewer than nnn distinct values of the columns. If there are more distinct values than nnn then you end up with a height-balanced histogram. In any case, yo WILL get a histogram because that is what you requested. If you ask for a histogram with method_opt=>’… size nnn’ then I there is no reason to go with anything but size 254 – unless you deliberately want to force a height-balanced histogram for a column with fewer than 255 distinct values. But in that case you better know exactly what you are doing and you may actually be better off to not gather the histogram in that case but construct it the way you want manually.
If “size auto” gives you only two buckets then that is either because of one of the cases we discussed, e.g. the column of a single-column unique or primary key, where gather_stats determined that a histogram makes no sense. Or the column has never been used in a where clause.

The quoted section from the book seems to be closely derived from a page of the Oracle Database 8.1.7 documentation which was modified and finally removed from later releases of the documentation.

Histograms are potentially useful when created on non-indexed columns, with the goal of improving cardinality estimates, which are used to determine join order and join type when multiple tables are referenced in a SQL statement.

Histograms are also potentially useful when the data is not skewed, helping to improve the cardinality estimates of range scans when outlier values are present (such as an out of range value taking the place of NULL values). See the test case in one of my comments above.

Regarding the statement, “Obviously, if the frequency for a specific value is very high, using the index won’t be the best choice,” the frequency of a value in a column is but one of several factors that the optimizer considers, but a high frequency of a value is not necessarily a problem if the use of the index avoids the need to visit the related table.

Regarding the bullet points that describes when histograms should not be used, “The column is not used in the WHERE clauses of the queries,” with the introduction of ANSI join syntax in Oracle Database 9.0.1, a column that only appears in JOIN clauses could potentially benefit from a histogram.

Prior to the introduction of adaptive cursor sharing in Oracle Database 11.1, bind variables when combined with bind variable peeking and histograms could generate execution plans that, while efficient for the first execution, were potentially considerably inefficient when different bind variable values were submitted during later executions of the SQL statement. Adaptive cursor sharing attempts to address the issues caused by the combination of bind variable peeking and histograms. In cases where the same value is always submitted for a comparison with a submitted bind variable, a histogram on the comparison column could significantly improve the optimizer’s cardinality estimates such that a more efficient execution plan is developed (consider a case when an index on a STATUS column is present, and that STATUS column contains the value of either PROCESSED or NOT PROCESSED). The book only mentioned that adaptive cursor sharing would be discussed in a later recipe – there was no comment in this section of the book regarding whether adaptive cursor sharing helped or further hindered the bullet-pointed items in the book.

Table analyzed.

Elapsed: 00:00:00.03
SQL> select column_name,count(*) from user_tab_histograms
2 where table_name=’EMP’
3 group by column_name;

no rows selected

SQL> get /tmp/1
1 begin
2 dbms_stats.gather_table_stats(
3 ownname => user,
4 tabname => ‘EMP’,
5 method_opt => ‘FOR ALL INDEXED COLUMNS SIZE 254′);
6* end;
SQL> /

colum column_name format a15
SQL> select column_name,count(*) from user_tab_histograms
2 where table_name=’EMP’
3 group by column_name;

COLUMN_NAME COUNT(*)
————— ———-
SYS_NC00009$ 12
ENAME 14
EMPNO 14

Elapsed: 00:00:00.02
SQL>

In other words, Oracle has duly collected stats on the single-column primary key (EMPNO). The version is 11G:

SQL> select * from v$version;

BANNER
——————————————————————————–
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 – 64bit Production
PL/SQL Release 11.2.0.3.0 – Production
CORE 11.2.0.3.0 Production
TNS for Linux: Version 11.2.0.3.0 – Production
NLSRTL Version 11.2.0.3.0 – Production

Elapsed: 00:00:00.01
SQL>

January and April PSU’s are applied. This is as new as it gets.

Histograms on the 4th of July, probably not the best combination.

Nice answers to start the dialog regarding this quote from the book. In the book, the third bullet point item mentioned that adaptive cursor sharing with bind peeking would be covered in a later recipe, but the bullet point item did not mention whether or not adaptive cursor sharing makes the bullet pointed statement stronger or weaker.

I found something related to the book quote, from the Oracle Database 8.1.7 documentation:
http://docs.oracle.com/cd/A87860_01/doc/server.817/a76992/stats.htm#27069

“Histograms are not useful for columns with the following characteristics:
* All predicates on the column use bind variables.
* The column data is uniformly distributed.
* The column is not used in WHERE clauses of queries.
* The column is unique and is used only with equality predicates.”

Equality predicates… that must be the tie in with the 4th of July.

Since “skewed values” is in bold in the book, I wonder if the definition of “skewed” is important. To me, that term means that some of the distinct values in a column have significant more (or less) rows with that value, when compared to other distinct values in the same column. Uniformly distributed could mean that all of the distinct values in a column have roughly the same number of rows sharing those distinct values.

Let’s set up a simple test case. Since I read somewhere that NULL values cause problems, I will use an “out of bound” value of 10,000 in place of any NULL that might naturally appear in a column. The table built will contain the numbers 0 through 100 in column C2 and 1 through 100 in column C3 with every 101st row considered to have a NULL value in that column (thus the value 10,000):

DROP TABLE T2 PURGE;
 
CREATE TABLE T2 AS
SELECT
  ROWNUM C1,
  MOD(ROWNUM,101) C2,
  DECODE(MOD(ROWNUM,101),0,10000,MOD(ROWNUM,101)) C3,
  RPAD('A',200,'A') C4
FROM
  DUAL
CONNECT BY
  LEVEL<=100000;
 
COMMIT;
 
EXEC DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>USER,TABNAME=>'T2',METHOD_OPT=>'FOR ALL COLUMNS SIZE 1')

In the above, statistics were collected on the table without histograms. Let’s try a couple of tests. First, I want to see the rows with either the maximum value in column C3, or the “out of bound” value representing a NULL.

 
SELECT /*+ GATHER_PLAN_STATISTICS */
  C1,
  C2,
  C3
FROM
  T2
WHERE
  C3 IN (100,10000);
 
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,'ALLSTATS LAST'));
 
SQL_ID  a7htzq376rch4, child number 0
-------------------------------------
SELECT /*+ GATHER_PLAN_STATISTICS */   C1,   C2,   C3 FROM   T2 WHERE
C3 IN (100,10000)
 
Plan hash value: 1513984157
 
------------------------------------------------------------------------------------
| Id  | Operation         | Name | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |      1 |        |   1980 |00:00:00.04 |    3168 |
|*  1 |  TABLE ACCESS FULL| T2   |      1 |   1980 |   1980 |00:00:00.04 |    3168 |
------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter(("C3"=100 OR "C3"=10000))

That worked well without a histogram, the cardinality estimate is exactly correct. If table T2 were then joined to another table, the accurate cardinality estimate could help the optimizer determine if table T2 should be the driving table, and which type of join method should be most efficient.

Let’s try again with a SQL statement that produces the same resultset as the above SQL statement:

SELECT /*+ GATHER_PLAN_STATISTICS */
  C1,
  C2,
  C3
FROM
  T2
WHERE
  C3 BETWEEN 100 AND 10000;
 
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,'ALLSTATS LAST'));
 
SQL_ID  g04bcqbxbut9p, child number 0
-------------------------------------
SELECT /*+ GATHER_PLAN_STATISTICS */   C1,   C2,   C3 FROM   T2 WHERE
C3 BETWEEN 100 AND 10000
 
Plan hash value: 1513984157
 
------------------------------------------------------------------------------------
| Id  | Operation         | Name | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |      1 |        |   1980 |00:00:00.02 |    3168 |
|*  1 |  TABLE ACCESS FULL| T2   |      1 |    100K|   1980 |00:00:00.02 |    3168 |
------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter(("C3">=100 AND "C3"<=10000))

That did not work so well. There are only 100,000 rows in the table, and the optimizer is predicting that roughly 100,000 rows will be returned by the query. If the resultset from table T2 were then joined with another table, the performance could be less than optimal due to the error in the cardinality calculation.

Let’s try again, this time trying to retrieve the values without a “NULL” in column C3:

SELECT /*+ GATHER_PLAN_STATISTICS */
  C1,
  C2,
  C3
FROM
  T2
WHERE
  C3 BETWEEN 1 AND 100;
 
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,'ALLSTATS LAST'));
 
SQL_ID  6z9pxyd4pguz8, child number 0
-------------------------------------
SELECT /*+ GATHER_PLAN_STATISTICS */   C1,   C2,   C3 FROM   T2 WHERE
C3 BETWEEN 1 AND 100
 
Plan hash value: 1513984157
 
------------------------------------------------------------------------------------
| Id  | Operation         | Name | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |      1 |        |  99010 |00:00:00.12 |    9457 |
|*  1 |  TABLE ACCESS FULL| T2   |      1 |   1980 |  99010 |00:00:00.12 |    9457 |
------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
--------------------------------------------------
   1 - filter(("C3"<=100 AND "C3">=1))

The optimizer also had difficulty with the cardinality calculation for this query. Not a big deal for this query because there is no join, and no index on column C3. But, what if there were a join or an index on column C3?

Let’s try again with a histogram on column C3:

EXEC DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>USER,TABNAME=>'T2',METHOD_OPT=>'FOR COLUMNS C3 SIZE 254',NO_INVALIDATE=>FALSE)

The first query:

SELECT /*+ GATHER_PLAN_STATISTICS */
  C1,
  C2,
  C3
FROM
  T2
WHERE
  C3 IN (100,10000);
 
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,'ALLSTATS LAST'));
 
SQL_ID  a7htzq376rch4, child number 0
-------------------------------------
SELECT /*+ GATHER_PLAN_STATISTICS */   C1,   C2,   C3 FROM   T2 WHERE
C3 IN (100,10000)
 
Plan hash value: 1513984157
 
------------------------------------------------------------------------------------
| Id  | Operation         | Name | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |      1 |        |   1980 |00:00:00.04 |    3168 |
|*  1 |  TABLE ACCESS FULL| T2   |      1 |   2265 |   1980 |00:00:00.04 |    3168 |
------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter(("C3"=100 OR "C3"=10000))

The cardinality estimate is less accurate than before the histogram was built, but the estimate is still reasonably close.

The second query:

SELECT /*+ GATHER_PLAN_STATISTICS */
  C1,
  C2,
  C3
FROM
  T2
WHERE
  C3 BETWEEN 100 AND 10000;
 
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,'ALLSTATS LAST'));
 
SQL_ID  g04bcqbxbut9p, child number 0
-------------------------------------
SELECT /*+ GATHER_PLAN_STATISTICS */   C1,   C2,   C3 FROM   T2 WHERE
C3 BETWEEN 100 AND 10000
 
Plan hash value: 1513984157
 
------------------------------------------------------------------------------------
| Id  | Operation         | Name | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |      1 |        |   1980 |00:00:00.03 |    3168 |
|*  1 |  TABLE ACCESS FULL| T2   |      1 |   2265 |   1980 |00:00:00.03 |    3168 |
------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter(("C3">=100 AND "C3"<=10000))

The cardinality estimate is significantly better than we saw before the histogram was built.

The third query:

SELECT /*+ GATHER_PLAN_STATISTICS */
  C1,
  C2,
  C3
FROM
  T2
WHERE
  C3 BETWEEN 1 AND 100;
  
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,'ALLSTATS LAST'));
 
SQL_ID  6z9pxyd4pguz8, child number 0
-------------------------------------
SELECT /*+ GATHER_PLAN_STATISTICS */   C1,   C2,   C3 FROM   T2 WHERE
C3 BETWEEN 1 AND 100
 
Plan hash value: 1513984157
 
------------------------------------------------------------------------------------
| Id  | Operation         | Name | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |      1 |        |  99010 |00:00:00.12 |    9457 |
|*  1 |  TABLE ACCESS FULL| T2   |      1 |  98863 |  99010 |00:00:00.12 |    9457 |
------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter(("C3"<=100 AND "C3">=1))

Again, the cardinality estimate is significantly better than we saw before the histogram was built.

—

Sorry, I might have skewed too far off topic. Any other comments? “What, if anything, is wrong with the above quote from the book?” I will withhold my comments in this article for at least 24 hours.