Setting up gnucash to use postgesql back end - close but no cigar ...

[John Ralls]

> On Mar 13, 2015, at 7:12 AM, Sébastien de Menten <sdementen at gmail.com> wrote:
> 
> 
> As for numbers, I looked into that rather extensively last summer. No existing decimal library was able to handle the range of fractions necessary for bitcoin to Indonesian Rupiyah while adequately controlling rounding and providing adequate performance, so I decided to stay with our rational numbers. It does have the disadvantage of moving most calculation out of the database, so we may have to revisit it later.
> 
> Hello John, 
> 
> I would be interested to have a bit more details on your findings in this respect. If you look at a library like libmpdec (http://www.bytereef.org/mpdecimal/doc/libmpdec/index.html <http://www.bytereef.org/mpdecimal/doc/libmpdec/index.html>), does it lack features or performance or both ? And with regard to performance, in which cases are the arithmetic operations the bottleneck in GnuCash ? Is it in some report calculation ? In the (de)serialisation ?
> 

Sebastien,

I posted the details in a couple of threads to gnucash-devel last summer.:
  http://lists.gnucash.org/pipermail/gnucash-devel/2014-May/037723.html->http://lists.gnucash.org/pipermail/gnucash-devel/2014-June/037755.html
  http://lists.gnucash.org/pipermail/gnucash-devel/2014-July/037888.html->http://lists.gnucash.org/pipermail/gnucash-devel/2014-August/037996.html->http://lists.gnucash.org/pipermail/gnucash-devel/2014-September/038072.html

The short summary is that even when I disabled dynamic allocation the performance was 2-4X worse than our rational class. I also had to write fuzzy comparison functions to get some of the existing tests to pass, and controlling rounding correctly proved very difficult.

Since the use of rational calculation is pervasive in the engine I took the position that any significant slowdown in numeric performance would be unacceptable; note that in addition to the numeric test performance I also used the GncLot tests and saw some of the worst performance problems there. Since the specific goal of redoing numerics was to gain enough significant digits to allow for bitcoin's 10**-8 plus some headroom (bitcoin support is a frequent user request) while at the same time handling reasonably large amounts (10**12) Indonesian Rupiah (10**5 to the US Dollar) and I was able to do that by rewriting the int128 class that underlies GncNumeric without a performance penalty I'm comfortable with the results.

Regards,
John Ralls