From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: Alexander Kuzmenkov <a.kuzmenkov@postgrespro.ru>,
        pgsql-hackers@lists.postgresql.org
Subject: Re: Performance improvements for src/port/snprintf.c
In-reply-to: <20180927011814.kpncoksuqq3gy44s@alap3.anarazel.de>
References: <2238.1534716465@sss.pgh.pa.us>
 <f5dd41da-911c-fd97-1b78-e0f8c0141897@postgrespro.ru>
 <15785.1536776055@sss.pgh.pa.us>
 <20180926220419.lorxpb564gakdjkz@alap3.anarazel.de>
 <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>
 <20180927011814.kpncoksuqq3gy44s@alap3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Wed, 26 Sep 2018 18:18:14 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <17057.1538012681.1@sss.pgh.pa.us>
Date: Wed, 26 Sep 2018 21:44:41 -0400
Message-ID: <17058.1538012681@sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> Reading around the interwebz lead me to look at ryu

> https://dl.acm.org/citation.cfm?id=3192369
> https://github.com/ulfjack/ryu/tree/46f4c5572121a6f1428749fe3e24132c3626c946

> That's an algorithm that always generates the minimally sized
> roundtrip-safe string output for a floating point number. That makes it
> insuitable for the innards of printf, but it very well could be
> interesting for e.g. float8out, especially when we currently specify a
> "too high" precision to guarantee round-trip safeity.

Yeah, the whole business of round-trip safety is a bit worrisome.
If we change printf, and it produces different low-order digits
than before, will floats still round-trip correctly?  I think we
have to ensure that they do.  If we just use strfromd(), then it's
libc's problem if the results change ... but if we stick in some
code we got from elsewhere, it's our problem.

BTW, were you thinking of plugging in strfromd() inside snprintf.c,
or just invoking it directly from float[48]out?  The latter would
presumably be cheaper, and it'd solve the most pressing performance
problem, if not every problem.

			regards, tom lane