Class SelectExpression

    • Method Detail

      • getQuantifiers

        @Nonnull
        public List<? extends Quantifier> getQuantifiers()
        Description copied from interface: RelationalExpression
        Return an iterator of references to the children of this planner expression. The iterators returned by different calls are guaranteed to be independent (i.e., advancing one will not advance another). However, they might point to the same object, as when Collections.emptyIterator() is returned. The returned iterator should be treated as an immutable object and may throw an exception if Iterator.remove() is called. The iterator must return its elements in a consistent order.
        Specified by:
        getQuantifiers in interface RelationalExpression
        Returns:
        an iterator of references to the children of this planner expression
      • canCorrelate

        public boolean canCorrelate()
        Description copied from interface: RelationalExpression
        Returns if this expression can be the anchor of a correlation. A correlation is always formed between three entities:
        1. the Quantifier that flows data
        2. 2. the anchor (which is a RelationalExpression) that ranges directly over the source
        3. 3. the consumers (or dependents) of the correlation which must be a descendant of the anchor.
        In order for a correlation to be meaningful, the anchor must define how data is bound and used by all dependents. For most expressions it is not meaningful or even possible to define correlation in such a way. For instance, a LogicalUnorderedUnionExpression cannot correlate (this method returns false) because it is not meaningful to bind a record from one child of the union while providing bound values to another. In another example, a logical select expression can correlate which means that one child of the SELECT expression can be evaluated and the resulting records can bound individually one after another. For each bound record flowing along that quantifier the other children of the SELECT expression can be evaluated, potentially causing more correlation values to be bound, etc. These concepts follow closely to the mechanics of what SQL calls a query block. The existence of a correlation between source, anchor, and dependents may adversely affect planning because a correlation always imposes order between the evaluated of children of an expression. This may or may not tie the hands of the planner to produce an optimal plan. In certain cases, queries written in a correlated way can be de-correlated to allow for better optimization techniques.
        Specified by:
        canCorrelate in interface RelationalExpression
        Returns:
        true if this expression can be the anchor of a correlation, false otherwise.
      • hashCode

        public int hashCode()
        Overrides:
        hashCode in class Object
      • subsumedBy

        @Nonnull
        public Iterable<MatchInfo> subsumedBy​(@Nonnull
                                              RelationalExpression candidateExpression,
                                              @Nonnull
                                              AliasMap aliasMap,
                                              @Nonnull
                                              IdentityBiMap<Quantifier,​PartialMatch> partialMatchMap)
        Description copied from interface: RelationalExpression
        Try to establish if otherExpression subsumes this one. If two expression are semantically equal (e.g. in structure or by other means of reasoning) they should exactly return the same records. There are use cases where semantic equality is too strict and not that useful. During index matching we don't necessarily need to know if two expressions produce the same result, we just need to know that the candidate scan produces a (non-proper) super multiset of records (the candidate therefore includes all records warranted by the query) and we can match query against that candidate. The difference between result set produced by the candidate and the query then must be corrected by applying compensation. The following tautologies apply:
        • If query and candidate are semantically equivalent, the query side should match to the candidate side without any compensation. In other words the query expression can simply be replaced by the candidate expression.
        • If the candidate is matched and we decide to rewrite this query expression with the appropriate top expression on the candidate side then it holds that the query expression is equivalent to the computed compensation of the match over the candidate scan.
        • A query cannot match to a candidate if it cannot be proven that the candidate cannot at least produce all the records that the query may produce.
        Specified by:
        subsumedBy in interface RelationalExpression
        Parameters:
        candidateExpression - the candidate expression
        aliasMap - a map of alias defining the equivalence between aliases and therefore quantifiers
        partialMatchMap - a map from quantifier to a PartialMatch that pulled up along that quantifier from one of the expressions below that quantifier
        Returns:
        an iterable of MatchInfos if subsumption between this expression and the candidate expression can be established
      • rewriteInternalPlannerGraph

        @Nonnull
        public PlannerGraph rewriteInternalPlannerGraph​(@Nonnull
                                                        List<? extends PlannerGraph> childGraphs)
        Description copied from interface: InternalPlannerGraphRewritable
        Method to rewrite the planner graph.
        Specified by:
        rewriteInternalPlannerGraph in interface InternalPlannerGraphRewritable
        Parameters:
        childGraphs - planner graphs of children expression that already have been computed
        Returns:
        a new planner graph that can combine the childGraphs in a meaningful way. Note that there is no obligation to use the childGraphs at all, this method can create a new independent planner graph completely from scratch.