Push the work down to the source instead of dragging the source into Trino
PostgreSQLQueries that previously scanned entire remote tables return to source-side execution, and cross-network data volume drops sharply. Customers generally find they can defer adding Trino workers because …
Overview
Starburst's value depends on connectors doing work at the source. When pushdown silently fails, Trino compensates by streaming entire tables across the network and filtering them in worker memory, which is the slowest possible way to answer the query. AceMQ finds where pushdown is breaking and fixes the conditions that break it.
Challenge
Pushdown failures are quiet. A query that should send a filtered, aggregated request to Snowflake or PostgreSQL instead issues a full table scan because a CAST on the predicate column defeated the connector's rewrite, or a function has no source equivalent, or the join key types differ across catalogs. Teams see slow queries and add workers, which increases cost without touching the actual problem.
Environment
Starburst Enterprise or Galaxy federating relational sources, object storage, and warehouse connectors across on-premises and cloud.
Approach
AceMQ reads EXPLAIN and EXPLAIN ANALYZE output for the slowest recurring queries to see exactly which operators the connector accepted and which stayed in Trino. Each blocked pushdown is traced to its cause — type mismatch, unsupported function, missing statistics — and fixed at the query, view, or connector configuration level. Cost-based optimization is then given the statistics it needs to pick sane join orders.
Solution
- 1EXPLAIN ANALYZE review of the slowest recurring queries to identify which predicates, aggregates, and joins failed to push down
- 2Type alignment across catalogs so join keys and filter columns stop forcing casts that defeat connector rewrites
- 3Connector-level configuration for predicate, aggregate, join, and TopN pushdown per source system
- 4Table statistics collection and ANALYZE scheduling so the cost-based optimizer picks the right join order and distribution
- 5Dynamic filtering configuration for star-schema joins across federated sources
- 6Materialized view and cache service design for the small number of cross-source joins that genuinely cannot push down
Outcome
Queries that previously scanned entire remote tables return to source-side execution, and cross-network data volume drops sharply. Customers generally find they can defer adding Trino workers because the cluster is no longer doing work the source database should have done.
Technologies
PostgreSQLRelated Use Cases
Starburst Trino Worker OOM Remediation
Stopping worker crashes caused by unbounded joins, missing spill configuration, and memory limits that do not match the concurrency the cluster actually sees.
Starburst Federation Readiness Assessment
Evaluating whether a federated query layer will actually work against a given set of source systems before the platform is committed to.
Need Starburst Architecture Guidance?
AceMQ's senior Starburst engineers have handled this exact type of engagement before. Whether you need architectural guidance, hands-on remediation, or an ongoing managed partnership, we're ready to help.