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

Hi,

On 2018-10-07 12:59:18 +0100, Andrew Gierth wrote:
> >>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
> 
>  Tom> Now, "shortest value that converts back exactly" is technically
>  Tom> cool, but I am not sure that it solves any real-world problem that
>  Tom> we have.
> 
> Well, it seems to me that it is perfect for pg_dump.
> 
> Also it's kind of a problem that our default float output is not
> round-trip safe - people do keep wondering why they can select a row and
> it'll show a certain value, but then doing WHERE col = 'xxx' on that
> value does not find the row. Yes, testing equality of floats is bad, but
> there's no reason to put in extra landmines.

+1


>  Tom> I'm also worried that introducing it would result in complaints like
>  Tom> https://www.postgresql.org/message-id/CANaXbVjw3Y8VmapWuZahtcRhpE61hsSUcjquip3HuXeuN8y4sg%40mail.gmail.com
> 
> Frankly for a >20x performance improvement in float8out I don't think
> that's an especially big deal.

+1. There's plenty complaints where we just say "sorry that it bothers
you, but these larger concerns made us that way".


> I do not see any obvious way to use this code to generate the same
> output in the final digits that we currently do (in the sense of
> overly-exact values like outputting 1.89999999999999991 for 1.9 when
> extra_float_digits=3).

But, why would that be required? Just to placate people wanting exactly
the same output as before?  I don't quite get how that'd be a useful
requirement.

Obviously we *do* need to support outputting non-exponent style output
where appropriate, but that should mostly be different massaging of
d2d()'s output, instead of calling to_chars() as the ryu upstream code
does.  ISTM we also need to support *reducing* the precision (for the
case where people intentionally reduce extra_float_digits), but that
similarly should be a SMOP, right?-

- Andres