|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2018-10-05 11:54:59 -0400, Tom Lane wrote:
>> I really think that what we ought to do is apply the floatout 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.
If it were a significant performance improvement, I'd be okay with that
conclusion, but my measurements say that it's not. The extra complication
is not free, and in my judgement it's not worth it.
We certainly do need to buy back the performance we lost in floatout,
but the hack I suggested does so --- on all platforms, not only Linux.
regards, tom lane
|Next Message||Andres Freund||2018-10-05 17:29:55||Re: Skylake-S warning|
|Previous Message||David Steele||2018-10-05 17:03:44||Re: pgsql: Make WAL segment size configurable at initdb time.|