Hi,
On 2018-10-03 14:01:35 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > So when using pg's snprintf() to print a single floating point number
> > with precision, we get nearly a 10% boost.
>
> I just tested that using my little standalone testbed, and I failed
> to replicate the result. I do see that strfromd is slightly faster,
> but it's just a few percent measuring snprintf.c in isolation --- in
> the overall context of COPY, I don't see how you get to 10% net savings.
I just tested your patch, and I see (best of three):
master:
16224.727 ms
hack-use-of-strfromd.patch:
14944.927 ms
So not quite 10%, but pretty close.
CREATE TABLE somefloats(id serial, data1 float8, data2 float8, data3 float8);
INSERT INTO somefloats(data1, data2, data3) SELECT random(), random(), random() FROM generate_series(1, 10000000);
VACUUM FREEZE somefloats;
COPY somefloats TO '/dev/null';
What difference do you see?
> So I continue to think there's something fishy about your test case.
>
> BTW, so far as I can tell on F28, strfromd isn't exposed without
> "-D__STDC_WANT_IEC_60559_BFP_EXT__", which seems fairly scary;
> what else does that affect?
My copy says:
#undef __GLIBC_USE_IEC_60559_BFP_EXT
#if defined __USE_GNU || defined __STDC_WANT_IEC_60559_BFP_EXT__
# define __GLIBC_USE_IEC_60559_BFP_EXT 1
#else
# define __GLIBC_USE_IEC_60559_BFP_EXT 0
#endif
And __USE_GNU is enabled by
#ifdef _GNU_SOURCE
# define __USE_GNU 1
#endif
So I don't think anything's needed to enable that in pg, given that we
define _GNU_SOURCE
Greetings,
Andres Freund
