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>,
        Andrew Gierth <andrew@tao11.riddles.org.uk>,
        Alexander Kuzmenkov <a.kuzmenkov@postgrespro.ru>
Subject: Re: Performance improvements for src/port/snprintf.c
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>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Tue, 02 Oct 2018 23:09:36 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <25582.1538569214.1@sss.pgh.pa.us>
Date: Wed, 03 Oct 2018 08:20:14 -0400
Message-ID: <25583.1538569214@sss.pgh.pa.us>
Precedence: bulk

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