Overview | Package | Class | Use | Tree | Deprecated | Index | Help
PREV CLASS NEXT CLASS | FRAMES NO FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD

## org.modeshape.graph.query.optimize
Class RaiseSelectCriteria

    java.lang.Object
      org.modeshape.graph.query.optimize.RaiseSelectCriteria

All Implemented Interfaces:
  OptimizerRule

    @Immutable
    public class RaiseSelectCriteria

extends Object
implements OptimizerRule

An `optimizer rule` that moves up higher in the plan any SELECT node that appears below a JOIN node and that applies to selectors that are on the other side of the join.

This step is often counterintuitive, since one of the best optimizations a query optimizer can do is to `push down SELECT nodes` as far as they'll go. But consider the case of a SOURCE node that appears below a JOIN, where the SOURCE node is a view. The optimizer `replaces the SOURCE node with the view definition`, and if the view definition includes a SELECT node, that SELECT node appears below the JOIN. Plus, that SELECT node is already pushed down as far as it can go (assuming the view isn't defined to use another view). However, the JOIN may use the same selector on the opposite side, and it may be possible that the same SELECT node may apply to the other side of the JOIN. In this case, we can push up the SELECT node higher than the JOIN, and then the push-down would cause the SELECT to be copied to both sides of the JOIN.

Here is an example plan that involves a JOIN of two SOURCE nodes:

              ...
               |
             JOIN
            /     \
           /       SOURCE(SOURCE_NAME="t1")
          /
       SOURCE(SOURCE_NAME="v1")

If the right-side SOURCE references the "t1" table, and the left-side SOURCE references a view "v1" defined as " `SELECT * FROM t1 WHERE t1.id < 3`", then the `ReplaceViews` rule would change this plan to be:

               ...
               |
             JOIN
            /     \
           /       SOURCE(SOURCE_NAME="t1")
          /
        PROJECT
          |
        SELECT     applies the "t1.id < 3" criteria
          |
       SOURCE(SOURCE_NAME="t1")

Again, the SELECT cannot be pushed down any further. But the whole query can be made more efficient - because the SELECT on the left-side of the JOIN will include only those tuples from 't1' that satisfy the SELECT, the JOIN will only include those tuples that also satisfy this criteria, even though more tuples are returned from the right-side SOURCE.

In this case, the left-hand SELECT can actually be copied to the right-hand side of the JOIN, resulting in:

               ...
               |
             JOIN
            /     \
           /       SELECT   applies the "t1.id < 3" criteria
          /          |
        PROJECT    SOURCE(SOURCE_NAME="t1")
          |
        SELECT   applies the "t1.id < 3" criteria
          |
       SOURCE(SOURCE_NAME="t1")

Field Summary
`static RaiseSelectCriteria` | `INSTANCE`

Constructor Summary
`RaiseSelectCriteria()`

Method Summary
`protected PlanNode` | `copySelectNode(QueryContext context, PlanNode selectNode, SelectorName selectorName, String propertyName, SelectorName copySelectorName, String copyPropertyName)`
`PlanNode` | `execute(QueryContext context, PlanNode plan, LinkedList<OptimizerRule> ruleStack)` Optimize the supplied plan using the supplied context, hints, and yet-to-be-run rules.
`static Set<Column>` | `getColumnsReferencedBy(Visitable visitable)` Get the set of Column objects that represent those columns referenced by the visitable object.
`String` | `toString()`

Methods inherited from class java.lang.Object
`clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait`

Field Detail

### INSTANCE

    public static final RaiseSelectCriteria INSTANCE

Constructor Detail

### RaiseSelectCriteria

    public RaiseSelectCriteria()

Method Detail

### execute

    public PlanNode execute(QueryContext context,
                            PlanNode plan,
                            LinkedList<OptimizerRule> ruleStack)

  Optimize the supplied plan using the supplied context, hints, and yet-to-be-run rules.

  Specified by:
    `execute` in interface `OptimizerRule`
  Parameters:
    `context` - the context in which the query is being optimized; never null
    `plan` - the plan to be optimized; never null
    `ruleStack` - the stack of rules that will be run after this rule; never null
  Returns:
    the optimized plan; never null
  See Also:
    `OptimizerRule.execute(org.modeshape.graph.query.QueryContext, org.modeshape.graph.query.plan.PlanNode, java.util.LinkedList)`

### copySelectNode

    protected PlanNode copySelectNode(QueryContext context,
                                      PlanNode selectNode,
                                      SelectorName selectorName,
                                      String propertyName,
                                      SelectorName copySelectorName,
                                      String copyPropertyName)

### toString

    public String toString()

  Overrides:
    `toString` in class `Object`
  See Also:
    `Object.toString()`

### getColumnsReferencedBy

    public static Set<Column> getColumnsReferencedBy(Visitable visitable)

  Get the set of Column objects that represent those columns referenced by the visitable object.

  Parameters:
    `visitable` - the object to be visited
  Returns:
    the set of Column objects, with column names that always are the string-form of the `property name`; never null

Overview | Package | Class | Use | Tree | Deprecated | Index | Help
PREV CLASS NEXT CLASS | FRAMES NO FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD

Copyright © 2008-2012 JBoss, a division of Red Hat. All Rights Reserved.