Class MatchIntermediateRule
- java.lang.Object
-
- com.apple.foundationdb.record.query.plan.temp.PlannerRule<RelationalExpression>
-
- com.apple.foundationdb.record.query.plan.temp.rules.MatchIntermediateRule
-
@API(EXPERIMENTAL) public class MatchIntermediateRule extends PlannerRule<RelationalExpression>
Expression-based transformation rule that matches any non-leaf expression (called an intermediate expression) to a candidate expression in aMatchCandidate
. It yields matches of typePartialMatch
. This rule further seeds the memoization structure for partial matches that is kept as part ofExpressionRef
. It prepares further rules such as other applications ofMatchIntermediateRule
andAdjustMatchRule
.As an intermediate expression has children (and the candidate expression also has at least one child) we need to match up the quantifiers of the query expression to the quantifiers of the possible candidate expression in order to determine if the query expression is in fact subsumed by the candidate. The property of subsumption is defined as the ability of replacing the query expression with the candidate expression with the additional application of compensation. Equivalence between expressions is stronger than subsumption in a way that if two expressions are semantically equal, the compensation is considered to be a no op.
Example 1
query expression candidate expression +-----------+ +-----------+ | Union | | Union | +-----------+ +-----------+ / | \ / | \ / | \ / | \ +----+ +----+ +----+ +----+ +----+ +----+ | c1 | | c2 | | c3 | | ca | | cb | | cc | +----+ +----+ +----+ +----+ +----+ +----+
The matching logic between these two expressions needs to first establish if there is a mapping from
c1, c2, c3
toc1, cb, cc
such that the query expression can be subsumed by the candidate expression. In the example, we use union expressions that only define subsumption through equivalency. In other words, is there a mapping between the sets of quantifiers the expressions range over such that query expression and candidate expression are equal? It may be that no such mapping exist in which case subsumption cannot be established and this rule does not yield matches. It can also be that there are multiple such matches in which case we yield more than one partial match back to the planner. The expected "successful" outcome would be for this rule to yield exactly one match.The described problem is referred to as exact matching. To make matters more complicated, it can be that the query expression can be subsumed by the candidate expression even though the sets of quantifiers do not have the same cardinality. This is referred to as non-exact matching.
Example 2
query expression candidate expression +-----------+ +-----------+ | Select | | Select | +-----------+ +-----------+ / \ exists / | \ / \ / | \ +----+ +----+ +----+ +----+ +----+ | c1 | | c2 | | ca | | cb | | cc | +----+ +----+ +----+ +----+ +----+
For simplicity let us further assume the subtrees underneath
c1
andca
as well as the subtrees underneathc2
andcb
are already determined to be semantically equivalent. In this example we yield two partial matches, one forc1 -> ca
and one forc1 -> ca, c2 -> cb
. That is because the query expression can be replaced by the candidate expression in both cases (albeit with different compensations).Discussion as to why they are matching: for further explanations see
SelectExpression.subsumedBy(com.apple.foundationdb.record.query.plan.temp.RelationalExpression, com.apple.foundationdb.record.query.plan.temp.AliasMap, com.apple.foundationdb.record.query.plan.temp.IdentityBiMap<com.apple.foundationdb.record.query.plan.temp.Quantifier, com.apple.foundationdb.record.query.plan.temp.PartialMatch>)
. First note that the quantifier overc2
is existential (of typeQuantifier.Existential
. That also means that this quantifier does not ever positively contribute to the cardinality of the select expression. It only filters out the outer if the inner does not produce any records. In some sense it is very similar to a predicate. In fact it is a predicate defined on a sub query. Now ifca
is known to subsumec1
we can replace the query expression with the candidate expression if we also reapply the existential predicate (first match case). For the match that also mapsc2
tocb
we also know that the existential predicate overc2
is filtering out a record whencb
does not produce any records. On the flip side if there is more than one record being produced by the sub query on the query side the quantifier overcb
produces multiple records that now do contribute to the cardinality on the candidate side. That will need to be corrected by distinct-ing the output of the select expression if the match is utilized later on.
-
-
Nested Class Summary
Nested Classes Modifier and Type Class Description static class
MatchIntermediateRule.PartialMatchWithQuantifier
Partial match with a quantifier pulled up along with the partial match during matching.
-
Constructor Summary
Constructors Constructor Description MatchIntermediateRule()
-
Method Summary
All Methods Instance Methods Concrete Methods Modifier and Type Method Description Optional<Class<? extends Bindable>>
getRootOperator()
Returns the class of the operator at the root of the binding expression, if this rule uses a non-trivial binding.void
onMatch(PlannerRuleCall call)
-
Methods inherited from class com.apple.foundationdb.record.query.plan.temp.PlannerRule
getMatcher, toString
-
-
-
-
Method Detail
-
getRootOperator
public Optional<Class<? extends Bindable>> getRootOperator()
Description copied from class:PlannerRule
Returns the class of the operator at the root of the binding expression, if this rule uses a non-trivial binding. Used primarily for indexing rules for more efficient rule search.- Overrides:
getRootOperator
in classPlannerRule<RelationalExpression>
- Returns:
- the class of the root of this rule's binding, or
Optional.empty()
if the rule matches anything - See Also:
PlannerRuleSet
-
onMatch
public void onMatch(@Nonnull PlannerRuleCall call)
- Specified by:
onMatch
in classPlannerRule<RelationalExpression>
-
-