GoKawiilPostgres SELECT DISTINCT scans full result set despite indexing, DBOS finds
DBOS engineers debugging a Postgres-backed queue system found that SELECT DISTINCT was their most expensive query, even though it appeared simplest. They discovered that Postgres always scans every row matching a query's predicates when computing DISTINCT values, regardless of indexing or how few unique values exist, making it a poor fit for finding active partitions in a queue workload.
GoKawiil's interpretation of the reporting above, not reported fact.
This suggests a broader gap between how developers intuitively expect indexed queries to behave and how Postgres actually executes them, which could lead teams to unknowingly build slow, expensive operations into performance-critical paths like queue processing. The finding implies that engineers relying on SELECT DISTINCT for uniqueness lookups at scale may need alternative query patterns or workarounds to avoid unnecessary full scans.
- SELECT DISTINCT in Postgres always scans every row matching its predicates, regardless of indexing.
- DBOS discovered this while diagnosing performance issues in a partitioned, Postgres-backed queue system.
- The behavior can make DISTINCT queries unexpectedly costly even when few unique values are being retrieved.
Source: dbos.dev, 2026-09-24
Published there as: “Postgres SELECT DISTINCT Does Not Scale”
Read the original report → The summary and analysis above are GoKawiil's own, written from reporting by the source above. Facts and quotes belong to the original publisher.