RAC : Uncached TEMP SPACE

We parallelized a very big index (171GB) creation using this:

SQL> create UNIQUE index PK_TABLE_XXXX ON TABLE_XXXX
          (COL1
          ,COL2
          ,COL3
          ,COL4
          ,COL5)
     LOCAL
     TABLESPACE TBS_IDX_XXXX
     parallel 8
     NOLOGGING;

SQL> alter index PK_TABLE_XXXX noparallel;

Unfortunately we went in TEMP tablespace shortage after a couple of minutes of run

Error: ORA-12801
------------------------------
ORA-12801: erreur signalée dans le serveur de requête parallèle P001, instance xxxxxx(1)
ORA-01652: impossible d'étendre le segment temporaire de 128 dans le tablespace TEMP

SQL Plan Monitoring Details (Plan Hash Value=762135660)
=============================================================================
| Id |            Operation            |       Name       |  Rows   | Temp  |
|    |                                 |                  | (Estim) | (Max) |
=============================================================================
|  0 | CREATE INDEX STATEMENT          |                  |         |       |
|  1 |   PX COORDINATOR                |                  |         |       |
|  2 |    PX SEND QC (RANDOM)          | :TQ10000         |      3G |       |
|  3 |     PX PARTITION HASH ALL       |                  |      3G |       |
|  4 |      INDEX BUILD UNIQUE (LOCAL) | PK_TABLE_XXXX    |         |       |
|  5 |       SORT CREATE INDEX         |                  |      3G |   32G | -->
|  6 |        TABLE ACCESS FULL        | TABLE_XXXX       |      3G |       |
=============================================================================

This 32GB of maximum TEMP space looks very odd. I have already been working with this data base and I was practically sure that it allows more than this limit. So I looked at the v$sort_segment view:

SQL> compute sum Label 'Total Temp Used' of "Space(GB)" on report
SQL> break on report
SQL> select
       *
    from
    (select
            tablespace_name
           ,inst_id
           ,round((total_blocks*8192)/(1024*1024*1024),2) "Space(GB)"
      from
          gv$sort_segment order by 1,2);

TABLESPACE_NAME                    INST_ID  Space(GB)
------------------------------- ---------- ----------
TEMP                                     1      31.25
TEMP                                     2     656.22
                                           ----------
Total Temp Used                                687.47

Notice this 31.25GB of TEMP Space in instance 1. It looks to be closely related to the limit we’ve hit. And, indeed, the index creating script was started from instance 1 as shown in the corresponding Real Time SQL Monitoring report:

Global Information
------------------------------
 Status              :  DONE (ERROR)
 Instance ID         :  1                    --> spot this
 Session             :  xxxxxx(908:33137)
 SQL ID              :  1h8puyf4b3bw7
 SQL Execution ID    :  16777216
 Execution Started   :  01/25/2016 18:02:40
 First Refresh Time  :  01/25/2016 18:02:40
 Last Refresh Time   :  01/25/2016 18:04:07
 Duration            :  87s
 Module/Action       :  SQL Developer/-
 Service             :  xxxxxx_INST1
 Program             :  SQL Developer

This database is a RAC (11.2.0.3.0) with 2 nodes. It possesses a TEMP tablespace composed with 22 temporary files each of which has 32GB of size. This makes a total available TEMP space of 22*32 = 704GB. Having no clue about the reason for which Oracle has not been able to use the remaining TEMP space from instance 2, i asked to run the same script from instance 2 of the same database:

Global Information
------------------------------
 Status              :  DONE
 Instance ID         :  2   --> second instance
 Session             :  xxxxxx(401:717)
 SQL ID              :  1h8puyf4b3bw7
 SQL Execution ID    :  33554432
 Execution Started   :  01/26/2016 12:02:59
 First Refresh Time  :  01/26/2016 12:03:00
 Last Refresh Time   :  01/26/2016 12:30:07
 Duration            :  1628s
 Module/Action       :  SQL Developer/-
 Service             :  xxxxxx_INST2
 Program             :  SQL Developer       

SQL Plan Monitoring Details (Plan Hash Value=762135660)
=============================================================================
| Id |            Operation            |       Name       |  Rows   | Temp  |
|    |                                 |                  | (Estim) | (Max) |
=============================================================================
|  0 | CREATE INDEX STATEMENT          |                  |         |       |
|  1 |   PX COORDINATOR                |                  |         |       |
|  2 |    PX SEND QC (RANDOM)          | :TQ10000         |      3G |       |
|  3 |     PX PARTITION HASH ALL       |                  |      3G |       |
|  4 |      INDEX BUILD UNIQUE (LOCAL) | PK_TABLE_XXXX    |         |       |
|  5 |       SORT CREATE INDEX         |                  |      3G |   99G |
|  6 |        TABLE ACCESS FULL        | TABLE_XXXX       |      3G |       |
=============================================================================

Notice how the index creation, this time, completes without error, in about 27 minutes and consumes 99GB of TEMP space.
Here’s below the situation of the cached extends in gv$temp_extent_pool view immediately after the index successful creation :

SQL> compute sum Label 'Total Temp Used' of extents_cached on report
SQL> break on report
SQL> select inst_id
              , file_id
              , extents_cached
              , extents_used
        from gv$temp_extent_pool
        order by 1,2;

   INST_ID    FILE_ID EXTENTS_CACHED EXTENTS_USED
---------- ---------- -------------- ------------
         1          1          31994            8
         1          2              4            3
         1          3              0            0
         1          4              0            0
         1          5              3            0
         1          6              0            0
         1          7              1            0
         1          8              0            0
         1          9              0            0
         1         10              0            0
         1         11              0            0
         1         12              0            0
         1         13              0            0
         1         14              0            0
         1         15              0            0
         1         16              0            0
         1         17              0            0
         1         18              0            0
         1         19              0            0
         1         20              0            0
         1         21              0            0
         1         22              0            0
         2          1              0            0
         2          2          31995            0
         2          3          31999            0
         2          4          31999            0
         2          5          31996            0
         2          6          31999            0
         2          7          31998            0
         2          8          31999            0
         2          9          31999            0
         2         10          31999            0
         2         11          31999            0
         2         12          31999            0
         2         13          31999            0
         2         14          31999            0
         2         15          31999            0
         2         16          31999            0
         2         17          31999            0
         2         18          31999            1
         2         19          31999            0
         2         20          31999            0
         2         21          31999            0
         2         22          31999            0
                      --------------
Total Temp                    703973

SQL> select
           inst_id,
           tablespace_name,
           total_blocks,
           used_blocks,
           free_blocks
    from gv$sort_segment;

   INST_ID TABLESPACE_NAME                 TOTAL_BLOCKS USED_BLOCKS FREE_BLOCKS
---------- ------------------------------- ------------ ----------- -----------
         1 TEMP                                 4096256        1536     4094720
         2 TEMP                                86012288         128    86012160

We have a TEMP tablespace of 22 temporary files in a RAC configuration with 2 nodes. We can point out that, in instance 1, only the first temporary file that has been used. While in instance 2 we see that many extents have been uniformly allocated during the index creation.

SQL> select inst_id, trunc(bytes_cached/1024/1024/1024,2) Gbytes_cached from gv$temp_extent_pool;

   INST_ID GBYTES_CACHED
---------- -------------
         1         31.24
         1             0
         1             0
         1             0
         1             0
         1             0
         1             0
         1             0
         1             0
         1             0
         1             0
         1             0
         1             0
         1             0
         1             0
         1             0
         1             0
         1             0
         1             0
         1             0
         1             0
         1             0
         2             0
         2         31.24
         2         31.24
         2         31.24
         2         31.24
         2         31.24
         2         31.24
         2         31.24
         2         31.24
         2         31.24
         2         31.24
         2         31.24
         2         31.24
         2         31.24
         2         31.24
         2         31.24
         2         31.24
         2         31.24
         2         31.24
         2         31.24
         2         31.24
         2         31.24

44 rows selected.

Clearly for a reason I am not aware of, Instance 2 is refusing to uncache its temp extents to instance 1. Thanks to Riyaj Shamsudeen I knew that this situation could be due to the bug n° 14383007 which necessitates a patch to be solved.

Natural and Adjusted Hybrid Histogram

I was going to write a comment in this Jonathan Lewis article and have finally decided to write a blog article because it turned to be a long comment.  In the above mentioned article a reader was wondering why the bucket size of his modified data set is not obeying the minimum bucket size explained by Jonathan. Coincidentally I am writing a second article on Hybrid histogram for allthingsOracle where I have used my proper terminology to define two types of Hybrid histogram: a first type, which I have named ‘’Natural Hybrid’, is close to Jonathan’s original data set. And a second type, which I have named ‘’Adjusted Hybrid’’ is of the same vein as the reader modified data set. By  ‘’Natural Hybrid’’ type  I refer to a data set a data set that doesn’t qualify for a TOP-Frequency histogram because the threshold is greater than the naturally non-adjusted TopNRows. By ‘’Adjusted Hybrid’’ type, I am refering to a data set that initially satisfies the TOP-Frequency threshold but  fails to qualify for a TOP-Frequency histogram because Oracle finds at the middle of the process that the Adjusted TopNRows is greater than the threshold .

Let’s explain with example. Firstly here’s a model that qualify for a “Natural Hybrid” histogram:

SQL> create table t1 (id number, n1 number);
SQL> start InsT1.sql (see downloadable script at the end)

If we gather histogram for this data set of 37 distinct values using 20 buckets we will obtain a HYBRID histogram because the TOP-Frequency threshold accounts for 95 rows while the TOP-20 rows account for 80 rows as shown below:

SQL> select round ((20-1)/20 * 100) threshold from dual;

 THRESHOLD
----------
        95
SQL> select
         sum (cnt) TopNRows
    from (select
            n1
           ,count(*) cnt
         from t1
         group by n1
          order by count(*) desc
          )
   where rownum <= 20;

  TOPNROWS
----------
        80

In order to compute the Hybrid histogram information, Oracle will, in this case, use the bucket-frequency method explained by Jonathan Lewis. This method uses the minimum bucket size of 5 (not valid at the end of the data set though) and the unchanged initial number of bucket of 20 condition is respected. This is what I prefer labelling a Natural Hybrid histogram.

Let’s now use the reader model

create table t_jar (id number, n1 number);
insert into t_jar values (1,5 );
insert into t_jar values (1,5 );
insert into t_jar values (1,7 );
insert into t_jar values (1,7 );
insert into t_jar values (1,7 );
insert into t_jar values (1,7 );
insert into t_jar values (1,10 );
insert into t_jar values (1,12 );
insert into t_jar values (1,15 );
insert into t_jar values (1,15 );
insert into t_jar values (1,15 );
insert into t_jar values (1,20 );
commit;

This new data set of 6 distinct values over 12 rows will normally qualify for a TOP-3 Frequency histogram as it satisfies the threshold formula:

SQL> select round ((3-1)/3 * 12) threshold from dual;

 THRESHOLD
----------
         8
SQL> select
          sum (cnt) TopNRows
     from (select
             n1
            ,count(*) cnt
          from t_jar
          group by n1
          order by count(*) desc
             )
     where rownum >= 3;
  TOPNROWS
----------
         9

However, Oracle will not accept this at face value. It has to check if the low and high values are among the TOP-3 distinct values. If one of these values (or both) are not in the TOP-3, oracle will force it into the histogram, exclude the least repetitive value from the TOP-3, adjust the TopNRows and check again whether theses modifications have not altered the data set so that it still qualify or not for a TOP-Frequency histogram.

Here’s below a snippet of a corresponding dbms_stats trace file

SQL> exec dbms_stats.set_global_prefs ('TRACE', to_char (1+16));

SQL> BEGIN
        dbms_stats.gather_table_stats
          (user, 't_jar', method_opt =>; 'for columns n1 size 3');
     END;
    /
SQL> exec dbms_stats.set_global_prefs('TRACE', null);

DBMS_STATS:  NNV  NDV  AVG  MMX  HST  EP   RP   NNNP IND  CNDV HSTN HSTR  COLNAME
DBMS_STATS:   Y    Y    Y    Y    Y    Y    Y                        Y    N1
DBMS_STATS: Approximate NDV Options
DBMS_STATS: ACL,TOPN,NIL,NIL,RWID,U,U3U
DBMS_STATS: start processing top n values for column N1
DBMS_STATS: topn sql (len: 415):
DBMS_STATS: +++ select /*+
                       no_parallel(t) no_parallel_index(t)
			   dbms_stats cursor_sharing_exact use_weak_name_resl
                       dynamic_sampling(0) no_monitoring
			 xmlindex_sel_idx_tbl no_substrb_pad
			  */
		   substrb(N1,16,0,64),1,240) val,
                 rowidtochar(rowid) rwid
		  from "XXXX&".T_JAR& t
		  where rowid in(chartorowid('AAAJ4MAAEAACN4EAAA')
		              ,chartorowid('AAAJ4MAAEAACN4EAAC')
		    	       ,chartorowid('AAAJ4MAAEAACN4EAAI'))
		order by N1;
DBMS_STATS: remove last bucket: Typ=2 Len=2: c1,10 add: Typ=2 Len=2: c1,15
DBMS_STATS: removal_count: 1 total_nonnull_rows: 12 mnb:  3
DBMS_STATS: adjusted coverage: .667

Here’s the data set

SQL> select *
        from
       (select n1, count(1) cnt
         from t_jar
        group by n1
         order by n1);

        N1        CNT
---------- ----------
         5          2 -> low value
         7          4
        10          1
        12          1
        15          3
        20          1 -> high value
6 rows selected.

And here are the TOP-3 rows of the same data set:

SQL> select
          *
     from (select
             n1
            ,count(*) cnt
          from t_jar
          group by n1
          order by count(*) desc)
     where rownum <= 3;

        N1        CNT
---------- ----------
         7          4
        15          3
         5          2
3 rows selected.

Since the high value is not in the TOP-3 it will be forced into the histogram to the cost of the exclusion of the least repetitive TOP-3 values which is 5 in this case (frequency =2). But, before doing this task, Oracle has to check if, after this high value forcing, the data set is still qualifying for a Top-Frequency using the AdjustedTopNRows

 AdjustedTopNRows = TopNRows – 2 + 1 = 9-2+1 = 8

The AdjustedTopNRows is not any more greater than the threshold of 8 which signifies that Oracle will finally stop collecting TOP-Frequency and transform what it has already gathered into  a HYBRID histogram as shown in the same trace file (Trying to convert frequency histogram to hybrid)

DBMS_STATS: adjusted coverage: .667
DBMS_STATS: hist_type in exec_get_topn: 2048 ndv:6 mnb:3
DBMS_STATS: Evaluating frequency histogram for col: N1
DBMS_STATS:  number of values = 4, max # of buckects = 3, pct = 100, ssize = 12
DBMS_STATS:  Trying to convert frequency histogram to hybrid
DBMS_STATS:  > cdn 10, popFreq 4, popCnt 1, bktSize 4, bktSzFrc 0
DBMS_STATS:  Evaluating hybrid histogram:  cht.count 3, mnb 3, ssize 10, min_ssize 12, appr_ndv  TRUE, ndv 4, selNdv 1,
selFreq 4,
pct 100, avg_bktsize 3, csr.hreq TRUE, normalize TRUE
DBMS_STATS:   Histogram gathering flags: 7
DBMS_STATS:  Accepting histogram
DBMS_STATS: done_hist in process_topn: TRUE  csr.ccnt: 1
DBMS_STATS: Mark column N1 as top N computed
DBMS_STATS: Skip topn computed column N1 numhist: 0

This is what I have labelled an ‘’Adjusted Hybrid’’ histogram which is collected using a method that seems not involving the bucket size and which tends to be a top-frequency to hybrid conversion.

SELECT
        (row_number() over(order by ept_nbr)-1) NumBucket
        ,ept_nbr
        ,ept_act_val
        ,rpt_cnt
        ,ept_nbr - (lag(ept_nbr,1,0) over(order by ept_nbr)) "new bucket size"
        ,bucket_size "original bucket_size"
    FROM
        (SELECT
             ah.endpoint_number            ept_nbr
            ,ah.endpoint_actual_value      ept_act_val
            ,lag(ah.endpoint_number,1,0) over(order by ah.endpoint_number) ept_lag
            ,ah.endpoint_repeat_count rpt_cnt
            ,at.sample_size/at.num_buckets bucket_size
         FROM
            user_tab_histograms      ah
           ,user_tab_col_statistics  at
         WHERE ah.table_name  = at.table_name
         AND ah.column_name = at.column_name
         AND ah.table_name  = 'T_JAR'
         AND ah.column_name = 'N1'
       ) ORDER BY ept_nbr;

NUMBUCKET    EPT_NBR EPT_ACT_VA    RPT_CNT new bucket size original bucket_size
---------- ---------- ---------- ---------- --------------- --------------------
         0          2 5                   2               2                    4
         1          6 7                   4               4                    4
         2         10 20                  1               4                    4

In passing, the adjusted coverage mentioned in the above trace file is nothing than

AdjustedTopNRows/num_rows = 8/12 = 0.667

12c TOP-Frequency and the ’’half least popular value’’

Asking Oracle 12c to collect histogram for a data set with a number of distinct values (NDV) greater than the supplied number of buckets (N) will probably result in Hybrid histogram. There is indeed a probability that a TOP-Frequency histogram will be preferred to Hybrid histogram. To qualify for this alternative the data set must fulfil a pre-requisite: its TOP N distinct values should occupy a number of rows exceeding a certain threshold. If this pre-requisite is satisfied a kind of frequency histogram is collected for the TOP N values; hence the TOP-Frequency label. The remaining insignificant values will be neglected and not captured into the histogram tables. However, if the extreme values of the data set, that is the low and high values, are among the insignificant values, they will not be neglected. Tow TOP N distinct values will be selected to serve as a victim, excluded from the histogram information and replaced in the TOP N captured values by the low and high values. These victim values are those with the lowest frequency of appearance in the data set. Whether the low (or high) value is naturally present or forced in the TOP N captured values determines the threshold value and the cardinality estimate of the non-popular non-captured values and that of the low (or high) value as well.

Let’s put all what precedes in action.

create table TopFreq3 as
select
    rownum n1
	, case when mod(rownum, 100000)   = 0 then   90
	       when mod(rownum, 10000)    = 0 then   180
		  when mod(rownum, 1000)= 0 then   84
              when mod(rownum, 100)      = 0 then   125
              when mod(rownum,50)        = 2 then   7
              when mod(rownum-1,80)      = 2 then   22 
              when mod(rownum, 10)       = 0 then   19
              when mod(rownum-1,10)      = 5  then   15
              when mod(rownum-1,5)       = 1  then   11
              when trunc((rownum -1/3)) < 5  then   25
              when trunc((rownum -1/5)) < 20  then   33
	  else 42 
        end n2    
from dual
connect by level <= 2e2; 

SELECT n2, count(*)
FROM TopFreq3
GROUP BY n2
ORDER BY n2;

        N2   COUNT(*)
---------- ----------
         7          4 --> low value
        11         36
        15         20
        19         18
        22          3
        25          3
        33          8
        42        106
       125          2 --> high value

9 rows selected.

As shown above the engineered data set has 9 distinct values (over 200 rows) of which the TOP 8 seem to qualify for a TOP-Frequency histogram:

 undefine nb
undefine num_rows

 SELECT
       &&nb numberOfBuckets
      ,TopNRows
      ,round((1-(1/&&nb))* &&num_rows) Threshold
      ,case
        when (TopNRows – round((1-(1/&&nb))* &&num_rows)) > 0 then 'Qualify For TOP Frequency'
      else
         'Do not qualify For TOP Frequency'
      end TOPFreqDecision
   FROM
   (select
         sum (cnt) TopNRows
     from (select
             n2
           , count(*) cnt
         from TopFreq3
         group by n2
         order by count(*) desc
         )
      where rownum <= &&nb
    );
Enter value for nb: 8
Enter value for num_rows: 200

NUMBEROFBUCKETS   TOPNROWS  THRESHOLD TOPFREQDECISION
--------------- ---------- ---------- --------------------------------
              8        198        175 Qualify For TOP Frequency

The TOPNROWS being greater than the THRESHOLD a TOP-FREQUENCY will be preferred to the HYBRID histogram as shown in the following:

begin
  dbms_stats.gather_table_stats
       (user,'TopFreq3'
       ,method_opt =>'for columns n2 size 8');
end;
/

select
    column_name
   ,num_distinct
   ,num_buckets
   ,sample_size
   ,histogram
from
   user_tab_col_statistics
   where table_name = 'TOPFREQ3'
   and column_name  = 'N2';

COLUMN_NAME  NUM_DISTINCT NUM_BUCKETS SAMPLE_SIZE HISTOGRAM
------------ ------------ ----------- ----------- ---------------
N2                      9           8         200 TOP-FREQUENCY

Indeed as expected Oracle has gathered a TOP-FREQUENCY histogram for the TOP 8 distinct values as shown below:

select
       endpoint_actual_value value,
       endpoint_number,
       endpoint_number - (lag(endpoint_number,1,0) 
                         over(order by endpoint_number)) value_count
    from	
       user_tab_histograms
    where
       table_name = 'TOPFREQ3'
    and column_name = 'N2'
    order by
       endpoint_number
    ;

VALUE      ENDPOINT_NUMBER VALUE_COUNT
---------- --------------- -----------
7                        4           4 
11                      40          36
15                      60          20
19                      78          18
25                      81           3
33                      89           8
42                     195         106
125                    196           1 --> high value with a forced frequency 1

8 rows selected.

Notice by the way, how, despite the high value 125 is insignificant (count =2) it has been captured into the histogram with bizarrely a forced frequency of 1. For the sake of clarity let’s reprint below how the n2 column is spread in TopFreq3 table:

        N2   COUNT(*)
---------- ----------
         7          4 --> low value
        11         36
        15         20
        19         18
        22          3 --> first least popular value
        25          3 
        33          8
        42        106
       125          2 --> high value
9 rows selected.

Again notice how, the value 22 which is the first least popular value, has been removed from the TOP 8 to let its place for the insignificant high value 125 with a forced frequency of 1. This is how the TOP-Frequency seems to work. If the low and/or high value of the data set is naturally present in the TOP-N values then there will be no value exclusion-substitution. If however one of these values (or both) is outside the TOP-N values, then it must be included in the histogram information in place of the least popular value.

Let’s now check what cardinality estimates will be calculated for the non-captured values (including the excluded least popular value)

explain plan for select count(1) from TopFreq3 where n2= 22;

select * from table(dbms_xplan.display);

-----------------------------------------------
| Id  | Operation          | Name     | Rows  |
-----------------------------------------------
|   0 | SELECT STATEMENT   |          |     1 |
|   1 |  SORT AGGREGATE    |          |     1 |
|*  2 |   TABLE ACCESS FULL| TOPFREQ3 |     4 |
-----------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
   2 - filter("N2"=22)

How Oracle did work out this cardinality of 4? In this case Oracle is simply using the following formula:

E-Rows = num_rows * NewDensity

Where NewDensity is:

NewDensity = (sample_size-TopNRows)/(num_distinct-num_buckets)/sample_size
NewDensity = (200-198)/(9-8)/200 = .01

Finally applying the above mentioned cardinality estimation we get this:

E-Rows = num_rows * NewDensity
E-Rows = 200 * 0.01 = 2

But this is not equal to the correct cardinality estimation of 4. In fact, when one of the extreme values are forced into the histogram information the threshold (or TopNRows) are slightly adapted to take into account the exclusion-inclusion operation done between the extreme value and the least popular value:

AdjustedTopNRows = TopNRows – (count of least popular value) + 1 (forced value of 
                                                                  extreme value)

AdjustedTopNRows = 198 – 3 + 1 = 196

Apply this to the above cardinality estimation formula and you will get the correct estimation as shown below:

NewDensity = (200- 196)/(9-8)/200   = .02
E-Rows     = num_rows * NewDensity  = 200 * 0.02 = 4

And this is clearly backed by the corresponding 10053 trace file (spot the NewDensity and the BktCnt):

SINGLE TABLE ACCESS PATH 
  Single Table Cardinality Estimation for TOPFREQ3[TOPFREQ3] 
  SPD: Return code in qosdDSDirSetup: NOCTX, estType = TABLE
  Column (#2): 
    NewDensity:0.020000, OldDensity:0.002500 BktCnt:196.000000, PopBktCnt:195.000000, PopValCnt:7, NDV:9
  Column (#2): N2(NUMBER)
    AvgLen: 4 NDV: 9 Nulls: 0 Density: 0.020000 Min: 7.000000 Max: 125.000000
    Histogram: Top-Freq  #Bkts: 196  UncompBkts: 196  EndPtVals: 8  ActualVal: yes
  Table: TOPFREQ3  Alias: TOPFREQ3
    Card: Original: 200.000000  Rounded: 4  Computed: 4.000000  Non Adjusted: 4.000000

Bottom line: this article aims to restrain the enthusiasm of those using the ‘‘half least popular value’’ rule to get the selectivity of a non-popular frequency histogram before they extend it to the non-popular TOP-Frequency. It seems that this is not correct. And all in all, it seems that a non-popular TOP-FREQUENCY value is nothing else than a HYBRID non-popular value.