Use EXPLAIN for query plans
It’s useful to inspect the query plan before running heavy queries.
EXPLAIN shows how Trino handles joins, filters, and table scans.
Push down predicates
Write filters so you can push it down into Iceberg or Hive metadata. This reduces I/O and avoids unnecessary S3 reads.-
Bad example:
-
Good example:
Prune columns
Select only the required columns. This helps minimize shuffles and reduces the amount of data pulled from S3.-
Bad example:
-
Good example:
Optimize joins
As previously described, use join hints when table sizes are predictable. Broadcast a small dimension table to speed up the join, and apply partitioning for large fact-to-dimension joins.-
Bad example:
-
Good example:
Limit large scans
Apply filters andLIMIT clauses during early data exploration to avoid
scanning entire Iceberg tables.
-
Bad example:
-
Good example:
Pre-compute aggregations with CTAS or materialized views
For dashboards or recurring workloads, pre-compute heavy aggregations using Create Table as Select (CTAS) or materialized views. This reduces the load on Trino and improves Superset’s responsiveness.Additional resources
- To get an overview of Trino, refer to the Trino in NexusOne page.
- To learn practical ways to use Trino in the NexusOne environment, refer to the Trino hands-on examples page.
- For more details about Trino, refer to the Trino official documentation.
- If you are using the NexusOne portal and want to learn how to launch Trino, refer to the Launch a hosted app page.