push_subq hint tips

from http://www.dba-oracle.com/t_push_subq_hint.htm

In general, subqueries that are not merged into the outer query are sometimes executed as the last step in the execution plan. The push_subq hint is used to force all subqueries in the query block to be executed at the earliest possible place in the execution plan.  With push_subq, the subqueries are often executed before the outer query is executed.

 You also could use the with clause and the materialize hint, along with theprecompute_subquery hint that perform functionality similar to that of thepush_subq hint.

If the subquery is relatively inexpensive and reduces the number of rows significantly, then use of push_subq can improve the overall performance by evaluating the subquery as soon as possible.

Note that the push_subq hint has no effect if the subquery is using a sort merge join, or when the subquery references a remote table.

Additionally, Oracle suggests the use of push_subq when there are lots of non-indexed predicates where the majority of them come out TRUE and there is non-merged subquery that significantly reduces the number of rows.  The benefit of this application of push_subq is likely to only be with large data volumes that would like benefit from merging the subquery using UNNEST.

When you upgrade to Oracle 10g and beyond, you will find that push_subq is much more flexible.  With multiple subqueries, push_subq can be used to run individual subqueries at specific points earlier or later in the process:

• The push_subq hint can be moved into any subquery to be pushed

• The push_subq hint can be combined with the new qb_name() hint in order to name a specific subquery so it can be referenced by name. This use of push_subq allows the naming and pushing of any number of subqueries.

The syntax for the push_subq hint is:

/*+ push_subq [ ( @ qb_name) ] */

Conversely, the no_push_subq hint can be used to force non-merged queries to be evauated as the last step of the execution plan.