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-05 15:54:59 |
Message-ID: | 30726.1538754899@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:
> [ 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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David Steele | 2018-10-05 16:41:56 | Re: pgsql: Make WAL segment size configurable at initdb time. |
Previous Message | Catalin Iacob | 2018-10-05 15:47:36 | Re: NOTIFY and pg_notify performance when deduplicating notifications |