From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Gierth <andrew@tao11.riddles.org.uk>
Cc: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@lists.postgresql.org, Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Alexander Kuzmenkov <a.kuzmenkov@postgrespro.ru>
Subject: Re: Performance improvements for src/port/snprintf.c
Date: Sun, 07 Oct 2018 15:40:51 -0400
Message-ID: <14721.1538941251@sss.pgh.pa.us> (raw)
In-Reply-To: <878t3a9w7r.fsf@news-spur.riddles.org.uk>
References: <28321.1538585692@sss.pgh.pa.us>
<20181003170043.thdyezozi343dkuc@alap3.anarazel.de>
<2132.1538587869@sss.pgh.pa.us>
<20181003173639.tncawup2nnkp7vbv@alap3.anarazel.de>
<2435.1538588403@sss.pgh.pa.us>
<20181003174513.wxjxfj7eepytnlqa@alap3.anarazel.de>
<3316.1538589695@sss.pgh.pa.us>
<20181003183552.xaams6fau3i7oybj@alap3.anarazel.de>
<6797.1538592539@sss.pgh.pa.us>
<30726.1538754899@sss.pgh.pa.us>
<20181005165819.h7gdzcbwhnhofq2b@alap3.anarazel.de>
<87sh1jaiyq.fsf@news-spur.riddles.org.uk>
<13967.1538795773@sss.pgh.pa.us>
<87o9c7ahjh.fsf@news-spur.riddles.org.uk>
<15405.1538798355@sss.pgh.pa.us>
<87k1mvafjr.fsf@news-spur.riddles.org.uk>
<19798.1538837565@sss.pgh.pa.us>
<878t3a9w7r.fsf@news-spur.riddles.org.uk>
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> "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.
Perhaps. I was hoping for something we could slot into snprintf.c;
not being able to select the number of digits to output is clearly
a deal-breaker for that usage. But perhaps it's reasonable to allow
"extra_float_digits = 3" to be redefined as meaning "use the shortest
value that converts back exactly" in float[48]out.
However, it seems like it should still be on the table to look at
other code that just does sprintf's job faster (such as the stb
code Alexander mentioned). If anything like that is acceptable
for the general case, then we have to ask whether ryu is enough
faster than *that* code, not faster than what we have now, to
justify carrying another umpteen KB of independent code path
for the dump-and-restore case.
> 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.
Unfortunately, I do not think it's going to be acceptable for default
float output (as opposed to the dump/restore case) to become round-trip
safe. The number of people complaining today would be dwarfed by the
number of people complaining about extra garbage digits in their results.
There isn't any compromise that will make things "just work" for people
who are unaware of the subtleties of float arithmetic.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, andrew@tao11.riddles.org.uk, andres@anarazel.de, thomas.munro@enterprisedb.com, a.kuzmenkov@postgrespro.ru
Subject: Re: Performance improvements for src/port/snprintf.c
In-Reply-To: <14721.1538941251@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox