Re: On disable_cost
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Laurenz Albe <laurenz.albe@cybertec.at>,
Jim Finnerty <jfinnert@amazon.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2019-12-15T19:54:03Z
Lists: pgsql-hackers
Thomas Munro <thomas.munro@gmail.com> writes: > On Wed, Dec 11, 2019 at 7:24 PM Laurenz Albe <laurenz.albe@cybertec.at> wrote: >> Doesn't that rely on a specific implementation of double precision (IEEE)? >> I thought that we don't want to limit ourselves to platforms with IEEE floats. > Just by the way, you might want to read the second last paragraph of > the commit message for 02ddd499. The dream is over, we're never going > to run on Vax. Still, the proposed hack is doubling down on IEEE dependency in a way that I quite dislike, in that (a) it doesn't just read float values but generates new ones (and assumes that the hardware/libc will react in a predictable way to them), (b) in a part of the code that has no damn business having close dependencies on float format, and (c) for a gain far smaller than what we got from the Ryu code. We have had prior discussions about whether 02ddd499 justifies adding more IEEE dependencies elsewhere. I don't think it does. IEEE 754 is not the last word that will ever be said on floating-point arithmetic, any more than x86_64 is the last CPU architecture that anyone will ever care about. We should keep our dependencies on it well circumscribed. regards, tom lane
Commits
-
Doc: add detail about EXPLAIN's "Disabled" property
- 84b8fccbe5c2 18.0 landed
-
Adjust EXPLAIN's output for disabled nodes
- 161320b4b960 18.0 landed
-
Fix order of parameters in a cost_sort call
- 87b6c3c0b703 18.0 landed
-
Show number of disabled nodes in EXPLAIN ANALYZE output.
- c01743aa4866 18.0 landed
-
Treat number of disabled nodes in a path as a separate cost metric.
- e22253467942 18.0 landed
-
Remove grotty use of disable_cost for TID scan plans.
- e4326fbc60c4 18.0 landed