GnuCash Daily Source Diff

Linas Vepstas linas@linas.org
Fri, 9 Nov 2001 21:56:23 -0600


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.

> However, upon reading a Postgres
> book I found that in Postgres you don't actually need to use the FROM
> clause at all, i.e., Postgres can figure out the tables it needs from 
> the rest of the query. 

! I find that hard to beleive, but hey, if its true ...

I seem to remember a number of occasions where I would be building
queries by hand, and I'd have a partial from clause, and I'd get an 
error.  Even simple things that I knew worked fine in other DB's.  
So I got to be real careful about it.  I thought that was quirky 
of postgres or maybe some strict standard adherence thing .... 
Maybe this was a postgres 6.x limitation that is fixed in 7.x ??

But if you're sure it works, I can't argue ....

> Have you actually tested it to see if it craters performance? The 

 Uhh, no. ... I defer the decision to you.


> > > +                 sq->pq = stpcpy(sq->pq, "gncAccount.accountGuid = '");
> > > +                 sq->pq = stpcpy(sq->pq, " OR ");
> 
> I am simply implementing the semantics of the Query predicate, which is
> to match a split whose guid, transaction guid, or account guid matches
> the given guid. That is what the C code implements. 

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.  

> > >              case PR_SHRS: {
> > > -                     "gncEntry.accountGuid = gncAccount.accountGuid AND "
> > 
> > ???? Don't you need to know which account is to be matched ??
> 
> Yes, but that is now added further up if need_account is true.
> You also need that line if you want to sort on account fields,
> so I figured to do it the same as need_entry.

OK, it looked like a random deletion to me, maybe the slip of the
finger.

--linas


-- 
pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas@linas.org>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933