fix(sql): order-by ignored in sub-queries of aggregation#6414
fix(sql): order-by ignored in sub-queries of aggregation#6414
Conversation
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the WalkthroughThis PR fixes an issue where ORDER BY clauses in subqueries were being discarded during GROUP BY operations. The fix forces the order-by mnemonic to Changes
Sequence DiagramsequenceDiagram
participant Query as Outer Query<br/>(ORDER BY ts)
participant Optimizer as SqlOptimiser
participant Subquery as Subquery<br/>(GROUP BY + Aggregate)
participant InnerOrder as Inner ORDER BY<br/>(t.ts, p.ts)
Query->>Optimizer: optimiseOrderBy()
alt Before Fix
Optimizer->>Subquery: Check model type
Note over Optimizer: Discards ORDER BY<br/>from subquery
Subquery->>Query: Returns unordered results
else After Fix
Optimizer->>Subquery: Check model type
Optimizer->>Subquery: Detect GROUP BY model
Optimizer->>Subquery: Force ORDER_BY_REQUIRED
Subquery->>InnerOrder: Preserve inner ordering
InnerOrder->>Query: Returns correctly ordered results
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes
Suggested reviewers
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
@CodeRabbit review |
✅ Actions performedReview triggered.
|
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
core/src/main/java/io/questdb/griffin/SqlOptimiser.java (1)
3366-3369: ForcingORDER_BY_REQUIREDfor GROUP BY models correctly preserves nested ordering for order-sensitive aggregatesSetting
orderByMnemonic = ORDER_BY_REQUIREDwhenevermodel.getSelectModelType() == SELECT_MODEL_GROUP_BYensures that, for global aggregates likefirst(...)/last(...)without an explicitGROUP BYlist, the nested sub-query is optimised withtopLevelOrderByMnemonic == ORDER_BY_REQUIREDinstead ofORDER_BY_INVARIANT. That prevents the nested call tooptimiseOrderByfrom entering the default branch that clearsmodel.getOrderBy(), so innerORDER BYclauses are retained and aggregates that depend on row order behave correctly (fixing the reported bug).This is a conservative choice (it may keep more ordering than strictly necessary for order-insensitive aggregates) but is reasonable for correctness; any further refinement (e.g., distinguishing order-sensitive vs order-insensitive aggregates) would be an optional future optimisation, not required for this fix.
core/src/test/java/io/questdb/test/griffin/OrderByAdviceTest.java (1)
261-326: Consider adding inline documentation to explain the test's purpose.This test validates a critical fix for issue #6405, where ORDER BY clauses in subqueries were being incorrectly stripped during aggregation. Given the query's complexity (nested ORDER BY, JOIN with range conditions, order-dependent
first()aggregate), adding a brief comment would help future maintainers understand:
- Why the ORDER BY in the subquery (line 318) is essential for correctness
- That
first()depends on row order and would return incorrect results without preserved ordering- The specific scenario being tested (aggregation over joined subquery results)
Consider adding a comment like:
@Test public void testOrderByAggregateKeepsOrdering() throws Exception { // Regression test for issue #6405: ORDER BY in subqueries must be preserved // when used with order-dependent aggregates (first, last, first_not_null, last_not_null). // The optimizer was incorrectly removing ORDER BY clauses during GROUP BY operations, // causing first()/last() to return wrong results. execute(""" ...
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
core/src/main/java/io/questdb/griffin/SqlOptimiser.java(2 hunks)core/src/test/java/io/questdb/test/griffin/OrderByAdviceTest.java(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (35)
- GitHub Check: New pull request (SelfHosted Running tests with cover on linux-other)
- GitHub Check: New pull request (SelfHosted Running tests with cover on linux-pgwire)
- GitHub Check: New pull request (SelfHosted Running tests with cover on linux-cairo-sub)
- GitHub Check: New pull request (SelfHosted Running tests with cover on linux-cairo-root)
- GitHub Check: New pull request (SelfHosted Running tests with cover on linux-fuzz2)
- GitHub Check: New pull request (SelfHosted Running tests with cover on linux-fuzz1)
- GitHub Check: New pull request (SelfHosted Running tests with cover on linux-griffin-sub)
- GitHub Check: New pull request (SelfHosted Running tests with cover on linux-griffin-root)
- GitHub Check: New pull request (SelfHosted Other tests on linux-x64-zfs)
- GitHub Check: New pull request (SelfHosted Other tests on linux-x86-graal)
- GitHub Check: New pull request (SelfHosted Griffin tests on linux-x86-graal)
- GitHub Check: New pull request (Rust Test and Lint on linux-jdk17)
- GitHub Check: New pull request (Hosted Running tests on windows-other-2)
- GitHub Check: New pull request (Hosted Running tests on windows-other-1)
- GitHub Check: New pull request (Hosted Running tests on windows-pgwire)
- GitHub Check: New pull request (Hosted Running tests on windows-cairo-2)
- GitHub Check: New pull request (Hosted Running tests on windows-cairo-1)
- GitHub Check: New pull request (Hosted Running tests on windows-fuzz2)
- GitHub Check: New pull request (Hosted Running tests on windows-fuzz1)
- GitHub Check: New pull request (Hosted Running tests on windows-griffin-sub)
- GitHub Check: New pull request (Hosted Running tests on windows-griffin-base)
- GitHub Check: New pull request (Hosted Running tests on mac-other)
- GitHub Check: New pull request (Hosted Running tests on mac-pgwire)
- GitHub Check: New pull request (Hosted Running tests on mac-cairo-fuzz)
- GitHub Check: New pull request (Hosted Running tests on mac-cairo)
- GitHub Check: New pull request (SelfHosted Griffin tests on linux-x64-zfs)
- GitHub Check: New pull request (SelfHosted Other tests on linux-arm64)
- GitHub Check: New pull request (Hosted Running tests on mac-griffin)
- GitHub Check: New pull request (SelfHosted Griffin tests on linux-arm64)
- GitHub Check: New pull request (SelfHosted Cairo tests on linux-x64-zfs)
- GitHub Check: New pull request (SelfHosted Cairo tests on linux-x86-graal)
- GitHub Check: New pull request (SelfHosted Cairo tests on linux-arm64)
- GitHub Check: New pull request (Check Changes Check changes)
- GitHub Check: build
- GitHub Check: build
🔇 Additional comments (1)
core/src/main/java/io/questdb/griffin/SqlOptimiser.java (1)
3312-3320: Comment clarifies existing LIMIT/timestamp behavior; no functional changeThe updated comments around the
LIMITand explicit timestamp handling match the existing logic and improve readability without changing semantics. Nothing to fix here.
[PR Coverage check]😍 pass : 37 / 37 (100.00%) file detail
|
Fixes #6405
This PR fixes a bug from the
optimizeOrderBypass that was removing order-by in sub-queries of aggregations.Functions like
first/last/first_not_null/last_not_nullneeds to receive the rows in the expected order to work properly.Example