Dean Rasheed <dean.a.rash...@gmail.com> writes: > There's another complication though (if the threshold is made > configurable): the various numeric functions that use mul_var() are > immutable, which means that the results from the Karatsuba algorithm > must match those from the schoolbook algorithm exactly, for all > inputs.
That seems like an impossible standard to meet. What we'd probably have to do is enable Karatsuba only when mul_var is being asked for an exact (full-precision) result. This'd complicate the check condition further, possibly reaching the point where there is a visible drag on performance in the non-Karatsuba case. Another possible source of drag: if mul_var is now recursive, does it need a stack depth check? If we can prove that the number of recursion levels is no more than O(log(N)) in the number of input digits, it's probably safe to skip that ... but I see no such proof here. (In general I find this patch seriously undercommented.) > There's a wider question as to how many people use such big numeric > values -- i.e., how many people are actually going to benefit from > this? I don't have a good feel for that. I have heard of people doing calculations on bignum integers in Postgres, but they are very few and far between --- usually that sort of task is better done in another language. (No matter how fast we make mul_var, the general overhead of SQL expressions in general and type numeric in particular means it's probably not the right tool for heavy-duty bignum arithmetic.) There is definitely an argument to be made that this proposal is not worth the development effort and ongoing maintenance effort we'd have to sink into it. regards, tom lane