In 11g there are several innovations with regard to the cost-based optimizer:
null-aware anti-join
: interesting for me because I've faced a few days ago. When you have a query like: SELECT ... T2.Y and is a column that can have null values, 10g and earlier can use an execution plan that leads to an excess of consistent gets (mainly CPU), and then to a query very slow. In 11g it is possible the anti-join. Council
the excellent article Greg Rahn for those who want to learn more. Join Predicate Pushdown: When there is a join between a table and a view, the join condition (ie TX = VY) is computed directly in the table view that contains the column: TX = TV.Y . This will take advantage of any indexes present, even with that view contains group by, distinct and join
Moving the group by : in the case of a join with GROUP BY, the optimizer is able to move the group by and function within a group view, which reduces the lines on which to make the join.
- In many ways it seems that all these optimizations are designed to avoid delays due to common programming errors.
0 comments:
Post a Comment