Skip to content

Nightly upstream merge - #84

Merged
fuziontech merged 2 commits into
masterfrom
upstream-merge-nightly
Sep 27, 2026
Merged

fuziontech merged 2 commits into
masterfrom
upstream-merge-nightly

Conversation

@fuziontech

Copy link
Copy Markdown
Member

Merge the latest trinodb/trino master into the PostHog fork.

Upstream changes:

  • Add TopN pushdown on __time to the Druid connector.

Local validation:

  • JAVA_HOME=/usr/lib/jvm/jdk-25.0.4.1+1 ./mvnw install -pl plugin/trino-ducklake -am -DskipTests -Dair.check.skip-all=true

grvn-ht and others added 2 commits September 26, 2026 05:30
Push down ORDER BY __time ... LIMIT to Druid. Druid only supports
ordering by __time for non-aggregating queries, so any other sort key
is still handled by Trino. __time is never null in Druid, so the null
ordering requested by Trino can be ignored and the pushdown is
guaranteed.

Pushdown is only applied on a plain table scan, not on a handle that
already carries a limit or sort order, so the ORDER BY never ends up
on a subquery where Druid does not honor it.
@fuziontech
fuziontech requested a review from a team September 27, 2026 06:02

@bill-ph bill-ph left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed the PR description, diff, existing discussion, JDBC Top-N application and SQL construction, Druid connector tests, and Druid's scan ordering limits. No overengineering or scope creep concerns.

P1

  • Time-ordered scan pushdown can make large Top-N queries fail on Druid. Druid permits scan time ordering only when the requested limit is below druid.query.scan.maxRowsQueuedForOrdering (default 100,000) or the scanned segments stay below druid.query.scan.maxSegmentPartitionsOrderedInMemory (default 50). A query such as ORDER BY __time DESC LIMIT 100001 over enough partitions is now sent to Druid and fails, whereas Trino previously performed the sort. See Druid scan query documentation.

— Robo Bill v2 (gpt-6-sol, high reasoning)

}

@Override
public boolean supportsTopN(ConnectorSession session, JdbcTableHandle handle, List<JdbcSortItem> sortOrder)

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1: This accepts any Top-N limit, but Druid's time-ordered scan has resource limits: the requested limit must be below maxRowsQueuedForOrdering (default 100,000) or the scan must involve fewer than maxSegmentPartitionsOrderedInMemory partitions (default 50). With a larger limit on a sufficiently partitioned datasource, a query that Trino previously sorted locally now fails in Druid. Please gate this pushdown on a safe limit or provide a fallback for those scans. See Druid scan ordering.

@fuziontech
fuziontech merged commit 0cb20cf into master Sep 27, 2026
44 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants