First you need to work out what you did to get these results – then you can explain how I could reproduce the example.
As it is you haven’t told me how you collected the statistics, or what the table looks like, or how it’s indexed, or what query you ran. Moreover, you haven’t given me any assurance that the pieces of the trace file are equivalent, so you may have omitted lines from the first sample that you’ve shown in the second.

As far as “strange” is concerned – I think it’s possible that you collected stats the first time in a way that got 100% sample and no histogram, and in the second case generated a histogram off a small sample – although I would have expected 5e-7 for the second density. However, I don’t see the “NewDensity” figures, so I’m not sure you haven’t been running with optimizer_features_enable set to a lower value.

There is something strange with density with 11.2.0.2 ..

Table stats:
#Rows: 1000000 #Blks: 47414 AvgRowLen: 330.00 ChainCnt: 0.00

I have a column with only one distinct value.
AvgLen: 3 NDV: 1 Nulls: 0 Density: 1.000000

Now, after i’ve updated 1000 rows to null, the density dropped down .
AvgLen: 3 NDV: 1 Nulls: 1000 Density: 0.000001
Histogram: Freq #Bkts: 1 UncompBkts: 5452 EndPtVals: 1

any thoughts about this?

Very interesting. I wonder if it’s deliberate or an accident. Certainly worth checking in 11g. [Update: just ran your example in 11.1.0.6, and the effect does not appear there.]

This could be the answer to the concern I raised in the last paragraph about the increased complexity of imposing a selectivity for missing values – the old method will still work.

It seems that you can force the old (pre 10.2.0.4) behavior by just getting and setting the stats for the column, without changing anything. The only effect this appears to have is to set user_stats=’YES’ on dba_tab_columns. The 10053 trace does not give any clues as to why this works, it just seems to revert to using the column density again for missing histogram values, when user_stats=’YES’.

I don’t know whether this is a bug or the intended behavior, but it gives you a finer grain of control by allowing you to choose the columns for which you want the old or the new behavior, without having to “alter session set “_fix_control”=’5483301:off’”.

The following test case demonstrates:

------------------ Start of test case.
drop table x
/

create table x as
select 1 code,object_name from all_objects where rownum<=1000
union
select 2 code,object_name from all_objects where rownum<=1000
union
select 4 code,object_name from all_objects where rownum<=1000
;

exec dbms_stats.gather_table_stats(user,'X',method_opt => 'FOR ALL COLUMNS SIZE 254');

set autotrace traceonly explain

select * from x where code=2 -- value in histogram
/

select * from x where code=3 -- missing value
/

DECLARE
	l_distcnt NUMBER DEFAULT NULL;
	l_density NUMBER DEFAULT NULL;
	l_nullcnt NUMBER DEFAULT NULL;
	l_srec    DBMS_STATS.STATREC;
	l_avgclen NUMBER DEFAULT NULL;

BEGIN

	DBMS_STATS.GET_COLUMN_STATS (
		ownname	=>user,
		tabname	=>'X',
		colname	=>'CODE',
		distcnt	=>l_distcnt,
		density	=>l_density,
		nullcnt	=>l_nullcnt,
		srec	=>l_srec,
		avgclen	=>l_avgclen
	);

	DBMS_STATS.SET_COLUMN_STATS(
		ownname =>user,
		tabname =>'X',
		colname =>'CODE',
		distcnt =>l_distcnt,
		density =>l_density,
		nullcnt	=>l_nullcnt,
		srec	=>l_srec,
		avgclen	=>l_avgclen
	);

END;
/

select * from x where code=3
/

------------------ End of test case.

Here’s the output:

SQL> create table x as
  2  select 1 code,object_name from all_objects where rownum<=1000
  3  union
  4  select 2 code,object_name from all_objects where rownum<=1000
  5  union
  6  select 4 code,object_name from all_objects where rownum;=1000
  7  ;

Table created.

SQL>
SQL> exec dbms_stats.gather_table_stats(user,'X',method_opt => 'FOR ALL COLUMNS SIZE 254');

PL/SQL procedure successfully completed.

SQL>
SQL> set autotrace traceonly explain
SQL>
SQL> select * from x where code=2   -- value in histogram
  2  /

Execution Plan
----------------------------------------------------------
Plan hash value: 2941724873

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |   992 | 16864 |     5   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| X    |   992 | 16864 |     5   (0)| 00:00:01 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter("CODE"=2)
--
--  Value in histogram, cardinality = 992
--
SQL>
SQL> select * from x where code=3   -- missing value
  2  /

Execution Plan
----------------------------------------------------------
Plan hash value: 2941724873

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |   496 |  8432 |     5   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| X    |   496 |  8432 |     5   (0)| 00:00:01 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter("CODE"=3)
--
--  Value not in histogram, cardinality = 496 i.e. half the least value, as expected 
--  for 10.2.0.4.
--

SQL>
SQL> DECLARE
  2       l_distcnt     NUMBER       DEFAULT NULL;
  3       l_density     NUMBER       DEFAULT NULL;
  4       l_nullcnt     NUMBER       DEFAULT NULL;
  5       l_srec        DBMS_STATS.STATREC;
  6       l_avgclen     NUMBER       DEFAULT NULL;
  7
  8    BEGIN
  9
 10    DBMS_STATS.GET_COLUMN_STATS (
 11       ownname=> user,
 12       tabname=> 'X',
 13       colname=> 'CODE',
 14       distcnt=> l_distcnt,
 15       density=> l_density,
 16       nullcnt=> l_nullcnt,
 17       srec=> l_srec,
 18       avgclen=> l_avgclen);
 19
 20    DBMS_STATS.SET_COLUMN_STATS(
 21       ownname=> user,
 22       tabname=> 'X',
 23       colname=> 'CODE',
 24       distcnt=> l_distcnt,
 25       density=> l_density,
 26       nullcnt=> l_nullcnt,
 27       srec=> l_srec,
 28       avgclen=> l_avgclen);
 29
 30    END;
 31  /

PL/SQL procedure successfully completed.

SQL>
SQL> select * from x where code=3
  2  /

Execution Plan
----------------------------------------------------------
Plan hash value: 2941724873

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |     1 |    17 |     5   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| X    |     1 |    17 |     5   (0)| 00:00:01 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter("CODE"=3)

--
--  Cardinality = 1 i.e. the pre 10.2.0.4 behavior.
--

Regards,
Mike Barratt