From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@lists.postgresql.org, Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Andrew Gierth <andrew@tao11.riddles.org.uk>
Cc: Alexander Kuzmenkov <a.kuzmenkov@postgrespro.ru>
Subject: Re: Performance improvements for src/port/snprintf.c
Date: Wed, 03 Oct 2018 08:20:14 -0400
Message-ID: <25583.1538569214@sss.pgh.pa.us> (raw)
In-Reply-To: <20181003060936.zul7mfkcu5w7rotg@alap3.anarazel.de>
References: <20180926221814.el5nwmkez6zfmzbz@alap3.anarazel.de>
<14302.1538005507@sss.pgh.pa.us>
<20180926235821.zmpxqv66ob7v2ffi@alap3.anarazel.de>
<15882.1538007944@sss.pgh.pa.us>
<20180927004022.lfhffbj3roxzf5ca@alap3.anarazel.de>
<20180927005705.shbl3n5hq3t65n2j@alap3.anarazel.de>
<87r2hffwda.fsf@news-spur.riddles.org.uk>
<CAEepm=1-3AG2O25VNnLXsjCM3EHBLW=jyJtpp_AMGG6a-GRJZA@mail.gmail.com>
<6FEC34CD-B8C0-44E2-8D1F-2320568BDC78@anarazel.de>
<30551.1538517271@sss.pgh.pa.us>
<20181003060936.zul7mfkcu5w7rotg@alap3.anarazel.de>
Andres Freund <andres@anarazel.de> writes:
> On 2018-10-02 17:54:31 -0400, Tom Lane wrote:
>> Here's a version of this patch rebased over commit 625b38ea0.
> Cool. Let's get that in...
Cool, I'll push it shortly.
>> While there might be value in implementing our own float printing code,
>> I have a pretty hard time getting excited about the cost/benefit ratio
>> of that. I think that what we probably really ought to do here is hack
>> float4out/float8out to bypass the extra overhead, as in the 0002 patch
>> below.
> I'm thinking we should do a bit more than just that hack. I'm thinking
> of something (barely tested) like
Meh. The trouble with that is that it relies on the platform's snprintf,
not sprintf, and that brings us right back into a world of portability
hurt. I don't feel that the move to C99 gets us out of worrying about
noncompliant snprintfs --- we're only requiring a C99 *compiler*, not
libc. See buildfarm member gharial for a counterexample.
I'm happy to look into whether using strfromd when available buys us
anything over using sprintf. I'm not entirely convinced that it will,
because of the need to ASCII-ize and de-ASCII-ize the precision, but
it's worth checking.
> FWIW, I think there's still a significant argument to be made that we
> should work on our floating point IO performance. Both on the input and
> output side. It's a significant practical problem. But both a fix like
> you describe, and my proposal, should bring us to at least the previous
> level of performance for the hot paths. So that'd then just be an
> independent consideration.
Well, an independent project anyway. I concur that it would have value;
but whether it's worth the effort, and the possible behavioral changes,
is not very clear to me.
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, andres@anarazel.de, thomas.munro@enterprisedb.com, andrew@tao11.riddles.org.uk, a.kuzmenkov@postgrespro.ru
Subject: Re: Performance improvements for src/port/snprintf.c
In-Reply-To: <25583.1538569214@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