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: <20181003163717.oycshpp2hnctvtfj@alap3.anarazel.de>
References: <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>
 <25583.1538569214@sss.pgh.pa.us>
 <20181003155207.b3lqmovuv2c5c4id@alap3.anarazel.de>
 <26510.1538582852@sss.pgh.pa.us>
 <20181003161454.ozeioucsimjg5g6m@alap3.anarazel.de>
 <27041.1538583733@sss.pgh.pa.us>
 <20181003163717.oycshpp2hnctvtfj@alap3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Wed, 03 Oct 2018 09:37:17 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <28320.1538585692.1@sss.pgh.pa.us>
Date: Wed, 03 Oct 2018 12:54:52 -0400
Message-ID: <28321.1538585692@sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> It seems the general "use strfromd if available" approach is generally
> useful, even if we need to serialize the precision.

Agreed.

> Putting it into an
> inline appears to be helpful, avoids some of the otherwise precision
> related branches.  Do you have any feelings about which header to put
> the code in?  I used common/string.h so far.

I do not think it should be in a header, for two reasons:

(1) The need to use sprintf for portability means that we need very
tight constraints on the precision spec *and* the buffer size *and*
the format type (%f pretty much destroys certainty about how long the
output string is).  So this isn't going to be general purpose code.
I think just writing it into float[48]out is sufficient.

(2) It's already the case that most code trying to emit floats ought
to go through float[48]out, in order to have standardized treatment
of Inf and NaN.  Providing some other API in a common header would
just create a temptation to break that policy.

Now, if we did write our own float output code then we would standardize
Inf/NaN outputs inside that, and both of these issues would go away ...
but I think what we'd do is provide something strfromd-like as an
alternate API for that code, so we still won't need a wrapper.
And anyway it doesn't sound like either of us care to jump that hurdle
right now.

			regards, tom lane