Quando si utilizzano variabili di collegamento, Oracle è obbligato a utilizzare sfoltimento dinamico della partizione invece di potatura partizione statica . Il risultato è che Oracle non sa al momento dell'analisi a quali partizioni si accederà, poiché cambia in base alle variabili di input.
Ciò significa che quando si utilizzano valori letterali (invece di variabili di collegamento), sappiamo a quali partizioni accederà il tuo indice locale. Pertanto il count stopkey può essere applicato all'output dell'indice prima di sfoltire le partizioni.
Quando si utilizzano variabili di collegamento, l'partition range iterator deve capire a quali partizioni stai accedendo. Quindi ha un controllo per garantire che la prima delle tue variabili nelle operazioni intermedie abbia effettivamente un valore inferiore rispetto alla seconda (il filter operazione nel secondo piano).
Questo può essere facilmente riprodotto, come mostra il seguente test case:
create table tab (
x date,
y integer,
filler varchar2(100)
) partition by range(x) (
partition p1 values less than (date'2013-01-01'),
partition p2 values less than (date'2013-02-01'),
partition p3 values less than (date'2013-03-01'),
partition p4 values less than (date'2013-04-01'),
partition p5 values less than (date'2013-05-01'),
partition p6 values less than (date'2013-06-01')
);
insert into tab (x, y)
select add_months(trunc(sysdate, 'y'), mod(rownum, 5)), rownum, dbms_random.string('x', 50)
from dual
connect by level <= 1000;
create index i on tab(x desc, y desc) local;
exec dbms_stats.gather_table_stats(user, 'tab', cascade => true);
explain plan for
SELECT * FROM (
SELECT rowid FROM tab
where x between date'2013-01-01' and date'2013-02-02'
and y between 50 and 100
order by x desc, y desc
)
where rownum <= 5;
SELECT * FROM table(dbms_xplan.display(null, null, 'BASIC +ROWS +PARTITION'));
--------------------------------------------------------------------
| Id | Operation | Name | Rows | Pstart| Pstop |
--------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | |
| 1 | COUNT STOPKEY | | | | |
| 2 | VIEW | | 1 | | |
| 3 | SORT ORDER BY STOPKEY | | 1 | | |
| 4 | PARTITION RANGE ITERATOR| | 1 | 2 | 3 |
| 5 | COUNT STOPKEY | | | | |
| 6 | INDEX RANGE SCAN | I | 1 | 2 | 3 |
--------------------------------------------------------------------
explain plan for
SELECT * FROM (
SELECT rowid FROM tab
where x between to_date(:st, 'dd/mm/yyyy') and to_date(:en, 'dd/mm/yyyy')
and y between :a and :b
order by x desc, y desc
)
where rownum <= 5;
SELECT * FROM table(dbms_xplan.display(null, null, 'BASIC +ROWS +PARTITION'));
---------------------------------------------------------------------
| Id | Operation | Name | Rows | Pstart| Pstop |
---------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | |
| 1 | COUNT STOPKEY | | | | |
| 2 | VIEW | | 1 | | |
| 3 | SORT ORDER BY STOPKEY | | 1 | | |
| 4 | FILTER | | | | |
| 5 | PARTITION RANGE ITERATOR| | 1 | KEY | KEY |
| 6 | INDEX RANGE SCAN | I | 1 | KEY | KEY |
---------------------------------------------------------------------
Come nel tuo esempio, la seconda query può solo filtrare le partizioni in una key al momento dell'analisi, piuttosto che le partizioni esatte come nel primo esempio.
Questo è uno di quei rari casi in cui i valori letterali possono fornire prestazioni migliori rispetto alle variabili di associazione. Dovresti verificare se questa è una possibilità per te.
Infine, dici di volere 20 righe da ciascuna partizione. La tua richiesta così com'è non lo farà, ti restituirà solo le prime 20 righe in base al tuo ordine. Per 20 righe/partizione, devi fare qualcosa del genere:
select rd from (
select rowid rd,
row_number() over (partition by trx_id order by create_ts desc) rn
from OUT_SMS
where TRX_ID between ? and ?
and CREATE_TS between ? and ?
order by CREATE_TS DESC, TRX_ID DESC
) where rn <= 20
AGGIORNAMENTO
Il motivo per cui non ricevi il count stopkey ha a che fare con il filter operazione nella riga 4 del piano "cattivo". Puoi vederlo più chiaramente se ripeti l'esempio sopra, ma senza partizionamento.
Questo ti dà i seguenti piani:
----------------------------------------
| Id | Operation | Name |
----------------------------------------
| 0 | SELECT STATEMENT | |
|* 1 | COUNT STOPKEY | |
| 2 | VIEW | |
|* 3 | SORT ORDER BY STOPKEY| |
|* 4 | TABLE ACCESS FULL | TAB |
----------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter(ROWNUM<=5)
3 - filter(ROWNUM<=5)
4 - filter("X">=TO_DATE(' 2013-01-01 00:00:00', 'syyyy-mm-dd
hh24:mi:ss') AND "X"<=TO_DATE(' 2013-02-02 00:00:00', 'syyyy-mm-dd
hh24:mi:ss') AND "Y">=50 AND "Y"<=100)
----------------------------------------
| Id | Operation | Name |
----------------------------------------
| 0 | SELECT STATEMENT | |
|* 1 | COUNT STOPKEY | |
| 2 | VIEW | |
|* 3 | SORT ORDER BY STOPKEY| |
|* 4 | FILTER | |
|* 5 | TABLE ACCESS FULL | TAB |
----------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter(ROWNUM<=5)
3 - filter(ROWNUM<=5)
4 - filter(TO_NUMBER(:A)<=TO_NUMBER(:B) AND
TO_DATE(:ST,'dd/mm/yyyy')<=TO_DATE(:EN,'dd/mm/yyyy'))
5 - filter("Y">=TO_NUMBER(:A) AND "Y"<=TO_NUMBER(:B) AND
"X">=TO_DATE(:ST,'dd/mm/yyyy') AND "X"<=TO_DATE(:EN,'dd/mm/yyyy'))
Come puoi vedere, c'è un filter in più operazione quando si utilizzano le variabili bind che appaiono prima di sort order by stopkey . Ciò accade dopo l'accesso all'indice. Questo sta verificando che i valori per le variabili consentano la restituzione dei dati (la prima variabile in mezzo ha effettivamente un valore inferiore alla seconda). Questo non è necessario quando si usano i valori letterali perché l'ottimizzatore sa già che 50 è inferiore a 100 (in questo caso). Tuttavia, non sa se :a è minore di :b al momento dell'analisi.
Perché esattamente questo non lo so. Potrebbe essere una progettazione intenzionale di Oracle - non ha senso eseguire il controllo del tasto di arresto se i valori impostati per le variabili risultano in zero righe - o solo una svista.
