From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
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, 3 Oct 2018 10:00:43 -0700
Message-ID: <20181003170043.thdyezozi343dkuc@alap3.anarazel.de> (raw)
In-Reply-To: <28321.1538585692@sss.pgh.pa.us>
References: <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>
<28321.1538585692@sss.pgh.pa.us>
Hi,
On 2018-10-03 12:54:52 -0400, Tom Lane wrote:
> 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.
Well, the numbers suggest it's also useful to do so from snprintf - it's
not that rare that we output floating point numbers from semi
performance critical code, even leaving aside float[48]out. So I'm not
convinced that we shouldn't do this from within snprintf.c too. Now we
could open-code it twice, but i'm not sure I see the point.
If we just define the API as having to guarantee there's enough space
for the output format, I think it'll work well enough for now?
snprintf.c already assumes everything floating point can be output in
1024 chars, no?
Greetings,
Andres Freund
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: andres@anarazel.de, tgl@sss.pgh.pa.us, 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: <20181003170043.thdyezozi343dkuc@alap3.anarazel.de>
* 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