Radim Marek’s analysis of floating-point arithmetic in databases has a clear takeaway for developers: check your query plans. The problem he documents — identical queries returning different sums depending on row order — is not a bug. It is a feature of the IEEE 754 standard.
But it is a feature that can wreck financial reports, inventory totals, and any other calculation where precision matters. Marek’s work, titled “Same rows, different SUM,” walks through test cases.
In one, a query summing a column of numbers returned one value when sorted by one column and a different value when sorted by another. The difference came down to floating-point addition’s lack of associativity. (a + b) + c is not always a + (b + c) when fractions are involved. The computer gets close, but not exact.
So what do you do if you run a database and need consistent sums? Marek does not prescribe a single fix.
But his examples point toward options. One is to use fixed-point arithmetic instead of floating-point for money. That rule is well known.
Marek calls it so well drilled it has stopped being interesting. But his analysis shows that even developers who think they have accounted for it may still be vulnerable. The next step, for many teams, is to audit their own query logic.
If a query sums a column and does not force a specific row order, the database may process rows differently on each run. Parallel execution plans make this worse.
Marek’s test cases show this clearly. A sum that looks stable can shift when the database chooses a different execution path. Another option is to use decimal data types where the database supports them.
These store numbers exactly, avoiding the rounding that floating-point types introduce. But decimal types come with tradeoffs.
They are slower. They use more storage. For large datasets, the performance hit can be significant.
Marek’s analysis also suggests a simpler check: test your queries. Run the same sum on the same data but with different sort orders. If the results differ, you have a floating-point problem.
That test takes minutes. It costs nothing.
Yet Marek implies many developers skip it. The broader lesson is about assumptions. Most developers know that floating-point arithmetic is imprecise.
But knowing it and accounting for it are different things. Marek’s concrete examples show how the problem hides in plain sight.
The same rows, processed in a different order, produce a different sum. The difference may be small — a few cents, a fraction of a percent. But small errors compound.
For teams that need to fix this now, the decision is straightforward. Switch to fixed-point or decimal types for critical columns. Force deterministic row order in queries.
Or accept that sums may vary and build logic to handle that variance. Each choice has costs.
Marek does not say which is right. He shows the problem and lets the numbers speak. The encouraging part of his analysis is that it is not abstract.
He walks through concrete examples. Developers can replicate his tests.
They can adapt them to their own data. That is the practical next step: run the tests. See if your sums change.
If they do, decide how much precision you can afford to lose.
