TECH Signal 508
The DISTINCT in Your COUNT
↗
Using COUNT(DISTINCT ...) in PostgreSQL disables parallel query execution entirely, forcing a single-process serial scan that can spill large sorts to disk.
Any analytics query counting distinct values on a large table runs serially regardless of your worker configuration, which means it will be dramatically slower than an equivalent parallel query. The performance gap grows with table size, and no configuration or index can fix it.
Written by elseif from the cluster below · every claim links back to a sourceThe three things worth knowing
PostgreSQL cannot split a DISTINCT aggregate into partial states across workers because distinct counts from different slices cannot be correctly combined without exchanging the full set of values.
A plain COUNT(*) uses parallel workers, but adding DISTINCT collapses the entire plan to a single-process sort that may spill to disk.
The workaround is to rewrite the query by pushing the DISTINCT logic into a GROUP BY subquery, then counting the resulting groups.
THE CLUSTER