AWS Redshift Support
Redshift query tuning with distribution and sort keys.
Slow Redshift queries usually come from moving too much data between nodes, scanning more blocks than needed, or stale statistics. Distribution style and sort keys decide the first two. We read the query plans, change table design where it helps, and measure the result.
When You Need This
The situations where this work pays for itself.
Signs it is time
- Dashboards or ETL queries take minutes on Redshift
- EXPLAIN shows broadcast or redistribute steps on large tables
- Queries scan far more rows than they return
- Performance degraded as tables grew
- A table has no sort key or an unsuitable distribution
What you get
- Top slow queries with plans and root causes
- Distribution and sort key recommendations with test results
- Maintenance settings and statistics fixes
- Rewritten queries or materialized views where useful
How we do it
A clear, safe process you can follow along with.
1. Find the slow and frequent queries
We rank queries by total time using system views such as SYS_QUERY_HISTORY or STL_QUERY and look at queue time versus execution time.
2. Read the plan
EXPLAIN shows join steps and data movement. DS_BCAST_INNER or DS_DIST_BOTH on large tables means a lot of data is shipped between nodes, a sign of poor distribution choices.
3. Choose distribution
For large tables joined often, a shared DISTKEY on the join column co-locates rows. Small dimension tables can use DISTSTYLE ALL, and AUTO lets Redshift choose. We avoid keys with skew.
4. Choose sort keys
A sort key on the column most used in range filters, often a timestamp, lets Redshift skip blocks via zone maps. We review compound versus interleaved choices and whether automatic table optimization is already acting.
5. Fix statistics, vacuum and compression
We check stale statistics, unsorted regions and compression encodings, and run ANALYZE and VACUUM where automatic maintenance is not enough.
6. Rewrite problem queries
We remove SELECT *, push filters earlier, avoid functions on sort key columns, and consider materialized views for repeated aggregations.
7. Test on a copy and compare
Changing keys rebuilds a table. We test on a copy, compare runtimes and scanned blocks, then roll out and keep before and after numbers.
Mistakes we help you avoid
Common ways this goes wrong, and what we do instead.
Distributing on a skewed column
One node gets most of the data and sets the pace for the whole query.
Sorting on a column nobody filters by
It adds load cost with no read benefit.
Ignoring queue time
Slow can mean waiting for a slot, not slow execution. See workload management.
Frequently Asked Questions
What is the difference between DISTKEY and SORTKEY?
DISTKEY decides which node stores a row, which affects joins. SORTKEY decides the order within storage, which affects how many blocks a filter must read.
Should I use DISTSTYLE AUTO?
It is a sensible default because Redshift can adjust it as table size changes. Choose explicit keys when you know a dominant join pattern.
How do I find which Redshift queries are slow?
Use system views for query history, sort by total or average duration and check queue versus execution time. Then examine the plan with EXPLAIN.
Want Help With Redshift query tuning with distribution and sort keys?
Schedule an appointment. Tell us about your environment and we will outline the safest, highest-value approach.
Schedule Appointment › No commitment required