From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Inaccurate results from numeric ln(), log(), exp() and pow() |
Date: | 2015-09-16 15:54:56 |
Message-ID: | CAHyXU0yr0Ax7-LakA2TW6RzaaaYXFhyaP5JMQhdmeZS5ERDfdg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Sep 16, 2015 at 10:14 AM, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> wrote:
> On 16 September 2015 at 14:49, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>>> AFAICT, this kind of slowdown only happens in cases like this where a
>>> very large number of digits are being returned.
>>
>> Can you clarify "very large"?
>>
>
> I haven't done much performance testing because I've been mainly
> focussed on accuracy. I just did a quick test of exp() for various
> result sizes. For results up to around 50 digits, the patched code was
> twice as fast as HEAD. After that the gap narrows until at around 250
> digits they become about the same speed, and beyond that the patched
> code is slower. At around 450 digits the patched code is twice as
> slow.
>
> My guess is that no one is actually using it for numbers that large.
well, I'm sold :-).
(I certainly agree that a slow inaccurate answer is better than a fast
inaccurate one, but it's nice to know that reasonable users of these
functions won't be impacted)
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Dean Rasheed | 2015-09-16 16:03:55 | Re: Inaccurate results from numeric ln(), log(), exp() and pow() |
Previous Message | Nicolas Barbier | 2015-09-16 15:53:39 | Re: [PROPOSAL] Covering + unique indexes. |