|From:||Andres Freund <andres(at)anarazel(dot)de>|
|To:||Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>|
|Cc:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Alexander Kuzmenkov <a(dot)kuzmenkov(at)postgrespro(dot)ru>|
|Subject:||Re: Performance improvements for src/port/snprintf.c|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 2018-10-07 12:59:18 +0100, Andrew Gierth wrote:
> >>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.
> 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
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
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?-
|Next Message||Pavel Stehule||2018-10-12 05:51:50||Re: [HACKERS] [PATCH] Generic type subscripting|
|Previous Message||Andrew Dunstan||2018-10-12 03:29:28||Re: [HACKERS] removing abstime, reltime, tinterval.c, spi/timetravel|