Dean Rasheed <dean.a.rasheed@gmail.com> writes: > ... For example, exp() works for inputs up to 6000. However, if you > compute exp(5999.999) the answer is truly huge -- probably only of > academic interest to anyone. With HEAD, exp(5999.999) produces a > number with 2609 significant digits in just 1.5ms (on my ageing > desktop box). However, only the first 9 digits returned are correct. > The other 2600 digits are pure noise. With my patch, all 2609 digits > are correct (confirmed using bc), but it takes 27ms to compute, making > it 18x slower.
> AFAICT, this kind of slowdown only happens in cases like this where a > very large number of digits are being returned. It's not obvious what > we should be doing in cases like this. Is a performance reduction like > that acceptable to generate the correct answer? Or should we try to > produce a more approximate result more quickly, and where do we draw > the line?
FWIW, in that particular example I'd happily take the 27ms time to get the more accurate answer. If it were 270ms, maybe not. I think my initial reaction to this patch is "are there any cases where it makes things 100x slower ... especially for non-outrageous inputs?" If not, sure, let's go for more accuracy.
Agreed
Hopefully things can be made faster with less significant digits.
I figure this is important enough to trigger a maint release, but since we already agreed when the next one is, I don't see we need to do it any quicker, do we?
Well done Dean for excellent research.
--
Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
