Running the same SUM query on a PostgreSQL table of double precision floats can produce different results across executions without any data changes. The cause is parallel aggregation: workers split rows non-deterministically and return partial sums in varying order, and since floating-point addition is not associative, different groupings produce different rounding errors. Disabling parallelism yields a stable result, but that stable result is still wrong compared to the exact value. The real fix is using the numeric type for any column whose aggregate must be reproducible or reconcilable. For genuinely approximate data like sensor readings, accept the imprecision and avoid asserting exact equality on float aggregates.

12m read timeFrom postgr.es
Post cover image
Table of contents
The schemaFloating point does not associateWhy parallelism surfaces itIt was never really parallelismDeterministic is not the same as correctWhere it actually bitesPostgres already knows this is dangerousWhat to do about it
919 Impressions