Re: Performance improvements for src/port/snprintf.c - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Performance improvements for src/port/snprintf.c
Date
Msg-id 30726.1538754899@sss.pgh.pa.us
Whole thread Raw
In response to Re: Performance improvements for src/port/snprintf.c  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Performance improvements for src/port/snprintf.c  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> [ let's use strfromd ]

So I'm having second thoughts about this, based on the fact that
strfromd() in't strictly a glibc-ism but is defined in an ISO/IEC
standard.  That means that we can expect to see it start showing up
on other platforms (though a quick search did not find any evidence
that it has yet).  And that means that we'd better consider
quality-of-implementation issues.  We know that glibc's version is
fractionally faster than using sprintf with "%.*g", but what are
the odds that that will be true universally?  I don't have a warm
feeling about it, given that strfromd's API isn't a very good impedance
match to what we really need.

I really think that what we ought to do is apply the float[48]out hack
I showed in <30551.1538517271@sss.pgh.pa.us> and call it good, at least
till such time as somebody wants to propose a full-on reimplementation of
float output.  I don't want to buy back into having platform dependencies
in this area after having just expended a lot of sweat to get rid of them.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Catalin Iacob
Date:
Subject: Re: NOTIFY and pg_notify performance when deduplicating notifications
Next
From: Andres Freund
Date:
Subject: Re: Performance improvements for src/port/snprintf.c