Windows Without Neighbors

A metrics table is hash-partitioned on its primary key. Almost every dashboard query asks for all rows in a time window. Why do those queries run worse than they would under range partitioning on the timestamp?

The hash must be recomputed for every candidate row at read time, and that CPU cost dominates the query

Hashing scatters adjacent timestamps across every shard, so a window query becomes a fan-out to all shards instead of hitting one or two

Hash-partitioned shards cannot maintain local secondary indexes, so each shard falls back to a full table scan

Hash partitioning requires a directory lookup per row before it can be fetched, which adds a network round trip to every single row the query returns