SQL backend performance

[Phil Longstaff]

On Wed, 2010-02-24 at 09:59 -0500, Derek Atkins wrote:
> Donald Allen <donaldcallen at gmail.com> writes:
> 
> >> I think true measurements will be the only way to find out what causes delays
> >> where.
> >
> > Of course. I spent a big chunk of my career doing performance analysis
> > on various bits of complicated software and learned very young (the
> > hard way) that if you think you know how your software behaves and
> > where the time is going, you are probably wrong. Measurement, done
> > correctly, is the only way to get to the truth reliably. I sometimes
> > had to insist on measurement by people who worked for me who were as
> > cocky (and wrong) as I was when I was young :-)
> >
> > But until the measurements are done, there's no harm in doing some
> > educated guessing, so long as the guessing doesn't replace the
> > measuring. If you are frequently right, it can help you set your
> > measurement priorities. If you are frequently wrong, it reminds you
> > that you aren't too good at modeling the behavior of software in your
> > head.
> 
> For what it's worth, the old Postgres backend was dog slow too.
> 
> I certainly encourage you to perform profiling to determine where our
> bottlenecks are.

Another thing that I haven't done too much of is trying to add extra
indexes or optimize queries.  All SQL statements are logged to
gnucash.trace.  Feel free to add indexes and/or change queries to
improve performance.

In general, one major problem is that certain areas of the code just
assume that the data is loaded.  Until we remove those assumptions or
provide alternatives, it seemed the safer route to just load all data at
start time.

Phil