Jackie-Jiang commented on code in PR #19702:
URL: https://github.com/apache/pinot/pull/19702#discussion_r4187932291
##########
pinot-core/src/main/java/org/apache/pinot/core/plan/SelectionPlanNode.java:
##########
@@ -77,7 +77,9 @@ public Operator<SelectionResultsBlock> run() {
// Although it is a break of abstraction, some code, specially merging,
assumes that if there is an order by
// expression the operator will return a block whose selection result is a
priority queue.
int sortedColumnsPrefixSize = getSortedColumnsPrefix(orderByExpressions,
_queryContext.isNullHandlingEnabled());
- if (sortedColumnsPrefixSize > 0) {
+ // Literals (including constant-folded now()) count as sorted so a later
identifier can extend the prefix, but
+ // the partial-order operators require an identifier. A prefix of only
literals must use the general order-by path.
+ if (sortedColumnsPrefixSize > 0 && hasIdentifier(orderByExpressions,
sortedColumnsPrefixSize)) {
Review Comment:
Non-blocking: literals impose no ordering constraint, so we should ignore
them when determining ordering direction. For example, `ORDER BY now() DESC,
sorted_col ASC` should behave like `ORDER BY sorted_col ASC`, but the existing
`get(0).isAsc()` checks let the literal's direction affect planning.
Could we handle this by ignoring literals in direction selection and
relaxing the partial-order constructors' identifier requirement when the sorted
prefix contains only literals? If all ORDER BY expressions are literals, any
input order is valid, and the linear operator can stop after `LIMIT + OFFSET`
rows instead of scanning all matching rows through the general order-by
fallback. Non-literal expressions after a literal prefix would still need their
normal sorting. This can be addressed in a follow-up.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
