Jeff Davis <pgsql@j-davis.com> writes:
> But you have a point in that float4in() does slightly more work than
> strtof() to handle platform differences about NaN/Inf. I'm not sure how
> much to weigh that concern, but I agree that there is non-zero
> cognitive overhead here.
If we're speaking strictly about the reltuples value, I'm not hugely
concerned about that. reltuples should never be NaN or Inf. There
is a nonzero chance that it will round off to a fractionally
different value if we pass it through strtof/sprintf on the pg_dump
side, but nobody is really going to care about that. (Maybe our
own pg_dump test script would, thanks to its not-too-bright dump
comparison logic. But that script is never going to see reltuples
values that are big enough to be inexact in a float4.)
I do buy the better-preserve-it-exactly argument for other sorts
of statistics, where we don't have such a good sense of what might
matter.
regards, tom lane
