Class OrderBy
- All Implemented Interfaces:
NamedWriteable,Writeable,PostAnalysisVerificationAware,PostOptimizationPlanVerificationAware,TelemetryAware,Resolvable,PipelineBreaker,SortAgnostic
-
Nested Class Summary
Nested classes/interfaces inherited from class org.elasticsearch.xpack.esql.plan.logical.LogicalPlan
LogicalPlan.StageNested classes/interfaces inherited from interface org.elasticsearch.common.io.stream.Writeable
Writeable.Reader<V>, Writeable.Writer<V> -
Field Summary
Fields -
Constructor Summary
Constructors -
Method Summary
Modifier and TypeMethodDescriptionbooleanbooleaninthashCode()info()order()voidpostAnalysisVerification(Failures failures) Allows the implementer to validate itself.Validates the implementing expression - discovered failures are reported to the givenFailuresclass.replaceChild(LogicalPlan newChild) voidwriteTo(StreamOutput out) Methods inherited from class org.elasticsearch.xpack.esql.plan.logical.UnaryPlan
child, inputSet, output, outputSet, replaceChildrenMethods inherited from class org.elasticsearch.xpack.esql.plan.logical.LogicalPlan
analyzed, childrenResolved, optimized, preAnalyzed, preOptimized, resolved, setAnalyzed, setOptimized, setPreAnalyzed, setPreOptimizedMethods inherited from class org.elasticsearch.xpack.esql.plan.QueryPlan
computeExpressions, computeReferences, expressions, forEachExpression, forEachExpression, forEachExpressionDown, forEachExpressionUp, references, transformExpressionsDown, transformExpressionsDown, transformExpressionsOnly, transformExpressionsOnly, transformExpressionsOnlyUp, transformExpressionsUp, transformExpressionsUpMethods inherited from class org.elasticsearch.xpack.esql.core.tree.Node
anyMatch, children, collect, collectFirstChildren, collectLeaves, doCollectFirst, forEachDown, forEachDown, forEachDownMayReturnEarly, forEachProperty, forEachPropertyDown, forEachPropertyOnly, forEachPropertyUp, forEachUp, forEachUp, nodeName, nodeProperties, nodeString, propertiesToString, replaceChildrenSameSize, source, sourceLocation, sourceText, toString, transformChildren, transformDown, transformDown, transformDown, transformNodeProps, transformPropertiesDown, transformPropertiesOnly, transformPropertiesUp, transformUp, transformUp, transformUp
-
Field Details
-
ENTRY
-
-
Constructor Details
-
OrderBy
-
-
Method Details
-
writeTo
- Specified by:
writeToin interfaceWriteable- Throws:
IOException
-
getWriteableName
- Specified by:
getWriteableNamein interfaceNamedWriteable
-
info
- Specified by:
infoin classNode<LogicalPlan>
-
replaceChild
- Specified by:
replaceChildin classUnaryPlan
-
order
-
telemetryLabel
- Specified by:
telemetryLabelin interfaceTelemetryAware- Returns:
- the label reported in the telemetry data. Only needs to be overwritten if the label doesn't match the class name.
-
expressionsResolved
public boolean expressionsResolved()- Specified by:
expressionsResolvedin classLogicalPlan
-
hashCode
public int hashCode() -
equals
-
postAnalysisVerification
Description copied from interface:PostAnalysisVerificationAwareAllows the implementer to validate itself. This usually involves checking its internal setup, which often means checking the parameters it received on construction: their data or syntactic type, class, their count, expressions' structure etc. The discovered failures are added to the givenFailuresobject.It is often more useful to perform the checks as extended as it makes sense, over stopping at the first failure. This will allow the author to progress faster to a correct query.
Example: the
Filterclass, which models the WHERE command, checks that the expression it filters on -condition- is of a Boolean or NULL type:@Override void postAnalysisVerification(Failures failures) { if (condition.dataType() != NULL && condition.dataType() != BOOLEAN) { failures.add(fail(condition, "Condition expression needs to be boolean, found [{}]", condition.dataType())); } }- Specified by:
postAnalysisVerificationin interfacePostAnalysisVerificationAware- Parameters:
failures- the object to add failures to.
-
postOptimizationPlanVerification
Description copied from interface:PostOptimizationPlanVerificationAwareValidates the implementing expression - discovered failures are reported to the givenFailuresclass.Example: the SORT command,
OrderBy, can only be executed currently if it can be associated with a LIMITLimitand together transformed into aTopN(which is executable). The replacement of the LIMIT+SORT into a TopN is done at the end of the optimization phase. This means that any SORT still existing in the plan post optimization is an error. However, there can be a LIMIT in the plan, but separated from the SORT by an INLINE STATS; in this case, the LIMIT cannot be pushed down near the SORT. To inform the user how they need to modify the query so it can be run, we implement this:@Override public BiConsumer<LogicalPlan, Failures> postOptimizationPlanVerification() { return (p, failures) -> { if (p instanceof InlineJoin inlineJoin) { inlineJoin.forEachUp(OrderBy.class, orderBy -> { failures.add( fail( inlineJoin, "unbounded SORT [{}] not supported before INLINE STATS [{}], move the sort after the INLINE STATS", orderBy.sourceText(), inlineJoin.sourceText() ) ); }); } else if (p instanceof OrderBy) { failures.add(fail(p, "Unbounded SORT not supported yet [{}] please add a LIMIT", p.sourceText())); } }; }If we didn't need to check the structure of the plan, it would have sufficed to implement the
PostOptimizationVerificationAwareinterface, which would simply check if there is an instance ofOrderByin the plan.- Specified by:
postOptimizationPlanVerificationin interfacePostOptimizationPlanVerificationAware- Returns:
- a consumer that will receive a tree to check and an accumulator of failures found during inspection.
-