From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, Alexander Kuzmenkov <a(dot)kuzmenkov(at)postgrespro(dot)ru> |
Subject: | Re: Performance improvements for src/port/snprintf.c |
Date: | 2018-10-03 16:54:52 |
Message-ID: | 28321.1538585692@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:
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2018-10-03 17:00:43 | Re: Performance improvements for src/port/snprintf.c |
Previous Message | Tom Lane | 2018-10-03 16:43:26 | Re: Performance improvements for src/port/snprintf.c |