Re: Performance improvements for src/port/snprintf.c

Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Tom> Yeah, one would hope. But I wonder whether it always produces the
> Tom> same low-order digits, and if not, whether people will complain.

> It won't produce the same low-order digits in general, since it has a
> different objective: rather than outputting a decimal value which is the
> true float value rounded to a fixed size by decimal rounding rules, it
> produces the shortest decimal value which falls within the binary float
> rounding interval of the true float value. i.e. the objective is to be
> able to round-trip back to float and get the identical result.

So I'm thinking that there are two, hopefully separable, issues here:

1. The algorithm for deciding how many digits to print.

2. The speed.

Now, "shortest value that converts back exactly" is technically cool,
but I am not sure that it solves any real-world problem that we have.
I'm also worried that introducing it would result in complaints like
https://www.postgresql.org/message-id/CANaXbVjw3Y8VmapWuZahtcRhpE61hsSUcjquip3HuXeuN8y4sg%40mail.gmail.com

As for #2, my *very* short once-over of the code led me to think that
the speed win comes mostly from use of wide integer arithmetic, and
maybe from throwing big lookup tables at the problem. If so, it's very
likely possible that we could adopt those techniques without necessarily
buying into the shortest-exact rule for how many digits to print.

> One option would be to stick with snprintf if extra_float_digits is less
> than 0 (or less than or equal to 0 and make the default 1) and use ryu
> otherwise, so that the option to get rounded floats is still there.
> (Apparently some people do use negative values of extra_float_digits.)
> Unlike other format-changing GUCs, this one already exists and is
> already used by people who want more or less precision, including by
> pg_dump where rount-trip conversion is the requirement.

I wouldn't necessarily object to having some value of extra_float_digits
that selects the shortest-exact rule, but I'm thinking maybe it should
be a value we don't currently accept.

regards, tom lane