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

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
Date: 2018-10-12 04:36:24
Message-ID: 20181012043624.xca3ksj3vzqatway@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

Hi,

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.

+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

In response to

Browse pgsql-hackers by date

  From Date Subject
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