If a downstream analyst says a dashboard is slow because a query over your Redshift or a thinner layer is scanning far too much data, how would you diagnose and optimize that end‑to‑end?

I would start by capturing the query text and running it in the Redshift Query Editor to view the execution plan. The plan shows which tables are scanned, the number of rows, and the cost of each step. I’d look for full table scans or large sorts that indicate missing distribution or sort keys. Next, I’d check the table statistics: run ANALYZE to update column stats and VACUUM to reclaim space and maintain sort order. If the query is scanning too much data, I’d add or adjust distribution keys to co‑locate frequently joined tables, and add sort keys to speed up range scans. I’d also consider creating materialized views for the most common aggregations, and use compression encodings to reduce I/O. For dashboards, I’d enable Redshift Spectrum or use a caching layer like Amazon QuickSight’s data caching. Finally, I’d monitor query performance over time with Redshift’s system tables (stl_query, stl_wlm_query) and set up alerts for long‑running queries. This end‑to‑end approach reduces scan size, improves join locality, and keeps dashboard latency within SLA.