org.modeshape.jcr.query.optimize
Class RaiseSelectCriteria
java.lang.Object
org.modeshape.jcr.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")
INSTANCE
public static final RaiseSelectCriteria INSTANCE
RaiseSelectCriteria
public RaiseSelectCriteria()
execute
public PlanNode execute(QueryContext context,
PlanNode plan,
LinkedList<OptimizerRule> ruleStack)
- Description copied from interface:
OptimizerRule
- 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 nullplan
- the plan to be optimized; never nullruleStack
- the stack of rules that will be run after this rule; never null
- Returns:
- the optimized plan; never null
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
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
Copyright © 2008-2012 JBoss, a division of Red Hat. All Rights Reserved.