From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Alexander Kuzmenkov <a(dot)kuzmenkov(at)postgrespro(dot)ru>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Performance improvements for src/port/snprintf.c |
Date: | 2018-09-27 01:44:41 |
Message-ID: | 17058.1538012681@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2018-09-27 01:46:45 | Re: Performance improvements for src/port/snprintf.c |
Previous Message | Tom Lane | 2018-09-27 01:30:25 | Re: Performance improvements for src/port/snprintf.c |