- Null-aware anti-join: interessante per me perché l'ho affrontato qualche giorno fa. Quando si ha una query del tipo:
SELECT... FROM T1 WHERE T1.X NOT IN (SELECT T2.Y where...);
e T2.Y è una colonna che può assumere valori nulli, 10g e precedenti possono utilizzare un piano di esecuzione che porta a un eccesso di consistent gets (sostanzialmente CPU), e quindi a una query molto lenta. In 11g è invece possibile l'anti-join.
Consiglio l'ottimo articolo di Greg Rahn per chi volesse approfondire l'argomento. - Join Predicate Pushdown: quando c'è una join tra una tabella e una view, la condizione di join (esempio T.X = V.Y) viene computata direttamente con la tabella nella view che contiene la colonna: T.X = TV.Y. In questo modo si sfruttano eventuali indici presenti, anche con view che contengono group by, distinct e join
- Spostamento del group by: nel caso di una join con group by, l'optimizer è in grado di spostare il group by e la funzione di gruppo all'interno di una view, che permette di ridurre le righe su cui fare la join.
- Eliminazione dei DISTINCT: l'optimizer analizza i vari blocchi di cui è formata una query, ed elimina i DISTINCT ove possibile.
Per molti versi sembra che tutte queste ottimizzazioni siano volte ad evitare rallentamenti dovuti ai più comuni errori di programmazione.
1 commento:
L'algoritmo del null-aware anti-join e` stato prontamente brevettato...
m2w
Posta un commento