Package com.apple.foundationdb.record.query.plan.temp.rules

Class 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 a MatchCandidate. It yields matches of type PartialMatch. This rule further seeds the memoization structure for partial matches that is kept as part of ExpressionRef. It prepares further rules such as other applications of MatchIntermediateRule and AdjustMatchRule.

    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 to c1, 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 and ca as well as the subtrees underneath c2 and cb are already determined to be semantically equivalent. In this example we yield two partial matches, one for c1 -> ca and one for c1 -> 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 over c2 is existential (of type Quantifier.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 if ca is known to subsume c1 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 maps c2 to cb we also know that the existential predicate over c2 is filtering out a record when cb 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 over cb 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.