User Generated Data and Cardinality Estimates

Question

Platform Information:
Windows Server 2003 R2
Oracle Enterprise Edition 10.2.0.4
Optimizer Parameters:
NAME                                 TYPE        VALUE
object_cache_optimal_size            integer     102400
optimizer_dynamic_sampling           integer     2
optimizer_features_enable            string      10.2.0.4
optimizer_index_caching              integer     90
optimizer_index_cost_adj             integer     30
optimizer_mode                       string      CHOOSE
optimizer_secure_view_merging        boolean     TRUE
Test Case:
var csv VARCHAR2(250);
exec :csv := '1,2,3,4,5,6,7,8,9,10';
EXPLAIN PLAN FOR WITH csv_to_rows AS
        SELECT UPPER(
                        TRIM(
                                SUBSTR
                                        txt
                                ,       INSTR (txt, ',', 1, level  ) + 1
                                ,       INSTR (txt, ',', 1, level+1) - INSTR (txt, ',', 1, level) -1
                )       AS token
        FROM    (
                        SELECT ','||:csv||',' txt
                        FROM dual
                )       t
        CONNECT BY LEVEL <= LENGTH(:csv)-LENGTH(REPLACE(:csv,',',''))+1
SELECT * FROM csv_to_rows;
SELECT  * FROM TABLE(DBMS_XPLAN.DISPLAY);
Results:
Execution Plan
Plan hash value: 2403765415
| Id  | Operation                     | Name | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT              |      |     1 |    19 |     2   (0)| 00:00:01 |
|   1 |  VIEW                         |      |     1 |    19 |     2   (0)| 00:00:01 |
|*  2 |   CONNECT BY WITHOUT FILTERING|      |       |       |            |          |
|   3 |    FAST DUAL                  |      |     1 |       |     2   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - filter(LEVEL<=LENGTH(:CSV)-LENGTH(REPLACE(:CSV,',',''))+1)
Statistics
          1  recursive calls
          0  db block gets
          0  consistent gets
          0  physical reads
          0  redo size
        502  bytes sent via SQL*Net to client
        396  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
         10  rows processed
Question:
Every once in a while I need to use [Tom Kyte's Varying in Lists|http://tkyte.blogspot.com/2006/06/varying-in-lists.html] method (for 9i as indicated in his blog entry) to convert a comma separated list to a "bindable" in list.
As one can see above the cardinality estimates are not correct. The execution plans I have seen from this method usually result in a nested loop join using an index. While this makes sense for small result sets it may not be the most efficient method with larger number of entries in the comma separated list.
Has anyone found a way to expose the correct or near correct cardinality to the optimizer at runtime? I can use the cardinality hint but the problem with that is that it must be defined as a scalar value and that may not work for all cases. The dynamic sampling won't work in this scenario because cardinality statistics already exist against DUAL.
I haven't noticed any detrimental effects in my environment so this may be purely an academic discussion but I thought I'd throw it out there :)

Answer 1

I have definitely considered using this as a possibility but I have tried to shy away from writing data (even temporarily) when all I'm looking to do is query data.I agree with you about hard-coding the cardinality values.
A silight variation on David's suggestion is to use the dynamic sampling hint to get the statistics at run-time. There will be a slight performance cost to do this.
Remember that all of the explain plan statistics are estimates, which may or may not be accurate. Usually they are good, but every once in a while they are incorrect.