[GNC-dev] Save as Postgres

[Greg Ingram]

I'm a long-time user and recently started to lurk on the -devel list. 
This problem may belong on -user but it seems like a problem for 
developers rather than my fellow users.

I have a set of book in a SQLite3 file and I'm trying to save it in 
PostgreSQL. It's still currently running. Here's a couple of lines from 
top:

     PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM TIME+ COMMAND
   42022 ingram    20   0 1600828 796256  93648 R 100.0   9.9 125:28.52 
gnucash

It keeps one CPU close to pegged. I can't tell what it's doing. The Save 
As dialog is still visible with the Save As button looking like it's 
been pressed. I don't see any relevant activity in system logs or 
GnuCash logs. As far as I can tell, it's never connected to the 
PostgreSQL server. It hasn't created any tables. I created the database 
after I aborted a previous try where the database didn't exist yet.

I'm using GnuCash 3.8, Build ID: 3.8b+(2019-12-29), as distributed with 
Kubuntu/Focal. I've also used a 3.8 from a flatpak on a machine with an 
older version of Kubuntu.

It's a pretty big data set: 112M SQLIte3 file with roughly 10K accounts, 
50K transactions, and 160K splits.

Is there hope it'll start writing to the database?

I searched for information related to what I'm seeing and most of what I 
found seemed to be about GnuCash 2.8 and earlier. There was some 
discussion about revamping GnuCash to take better advantage of SQL and 
that, at that time, it was still reading the entire database into memory.

Are things different now? Is there a performance gain to be had with a 
SQL back end? I switched from XML to SQLite3 because it seemed like the 
program was bogging down. And that's why I'm looking to try PostgreSQL now.

I've run into what may be a similar problem where I can no longer import 
transactions. Or I wasn't willing to wait long enough. Something I read 
back then suggested that some part of matching transactions to accounts 
involved a sort of exponential growth in the work it was doing. That's 
probably not clear but whatever it was led me to conclude that I had too 
much data for the program to handle. I work around the issue by 
importing into an almost empty set of accounts and the cut and paste 
into my official books.

Thanks for all your work,

- Greg