Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
> Tom> If you're concerned about arithmetic performance, there is a
> Tom> very obvious fix here: use double.
> Independently of this specific example, the obvious issue there is that
> there are applications for which double is simply not acceptable.
As the guy who last fooled with the numeric calculation algorithms in any
major way, I'm painfully aware that numeric is not necessarily more
accurate than double for anything more complicated than
addition/subtraction/multiplication. The example that was shown upthread
is pretty nearly a textbook case of something where I'd not believe that
numeric offers any accuracy improvement without *very* careful
investigation. In general, if your application is sufficiently
arithmetic-intensive that you need to care about the speed of calculations,
then it's not obvious which one to pick, and if I hear a knee-jerk "simply
not acceptable" I'm simply going to conclude that you haven't actually
studied the subject.
> As it stands, no extension can use the numeric type in any non-trivial
> way without paying a large penalty for repeated pallocs and data copies.
> Given that the ability to write C extensions easily is one of pg's great
> strengths, this is a defect that should be corrected.
> Tom> (It would still be orders of magnitude slower, no matter how
> Tom> much we were willing to destroy numeric.c's modularity
> Tom> boundary.)
> There is no need to expose any details of NumericVar's implementation;
> it would suffice to provide an interface to allocate NumericVars, and
> access to the functions.
I call BS on that. Exposing NumericVar is *already* violating numeric.c's
abstraction boundary. If somebody were to want to reimplement numeric for
more speed, changing that data structure and/or the usage conventions for
it would likely be one of the core things they need to do. As soon as we
expose the functions you're asking for, that becomes impossible.
regards, tom lane
