On Fri, 2001-11-09 at 19:56, Linas Vepstas wrote: > On Fri, Nov 09, 2001 at 01:26:06PM -0800, Dave Peticolas was heard to remark: > > > > Yes, I know, I was the one who originally pointed out to you > > that removing unneeded tables would improve performance (you remember > > the 10-minute startup times I saw?). > > Hmm, yeah. At some point, It seemed that it was time to look at > performance. I made 50 or 60 measurements, changing all kinds of > things ... it got pretty dizzying after a while.
I figured out why the orginal performance was so bad. Just a simple example shows why. For a populated GnuCash database, the following query returns 1 row: SELECT gncTransaction.* WHERE gncTransaction.transGuid='used-guid'; Note you don't have to specify any FROM clause at all, Postgres just picks it up from the syntactic analysis of the rest of the query. This query returns that same transaction for every account: SELECT gncTransaction.* FROM gncAccount WHERE gncTransaction.transGuid='used-guid'; So it seems when you explicitly reference a table in the FROM clause, postgres is going to join it no matter what. So in the queries with unneeded tables in the FROM clause, Postgres was spinning over the cross-product of all the unconstrained tables. > Hmm. Maybe we should change the C code? I dont' think this query type > is used anywhere at the moment, we may as well make it rational now, > rather than later. If someone in a higher level really does need > to do an 'or' over several tables, they can do this easily enough, > without loss of generality. Doing the 'or' at the low level just > impacts performance even for those who don't need it. That's fine by me. It should be used somewhere since it wasn't one of the original ones but shouldn't be hard to change. dave
msg01371/pgp00000.pgp
Description: PGP signature
