Re: Performance improvements for src/port/snprintf.c

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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-05 16:58:19
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


On 2018-10-05 11:54:59 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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(dot)1538517271(at)sss(dot)pgh(dot)pa(dot)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.

I'm not convinced. Because of some hypothetical platform that may
introduce strfromd() in a broken/slower manner, but where sprintf() is
correct, we should not do the minimal work to alleviate an actual
performance bottleneck in a trivial manner on linux? Our most widely
used platform? If we find a platform where it's borked, we could just
add a small hack into their platform template file.


Andres Freund

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2018-10-05 17:01:41 Re: SCRAM with channel binding downgrade attack
Previous Message Andres Freund 2018-10-05 16:54:47 Re: pgsql: Make WAL segment size configurable at initdb time.