Forum .LRN Q&A: Re: Details on our efforts at Sloan to improve .LRN performance

Collapse
6: Re: Details on our efforts at Sloan to improve .LRN performance (response to 1)
Posted by Dave Bauer on 09/23/04 03:18 PM
Rocael,

Can you give us more details or specific examples of why these are slow?

"Galileo is using postgres 7.4.3, and we have been fixing several queries with bad performance, stuff like:
* left join"

What kind of left joins are slow?

"* wheres x is not in (...)"
IN should perform well in PostgreSQL 7.4.x, maybe NOT IN is not optimized as well?

"* and some inline query function calls"
are these in the column spec of the query or ther WHERE clause?

Dave

Collapse
7: Re: Details on our efforts at Sloan to improve .LRN performance (response to 6)
Posted by Rocael Hernández Rizzardini on 09/23/04 05:45 PM
well, all of them related to the CR,
also we avoided the use of the CR views x & i since they are quite slow for the extra joins which most of the times are unnecesary.

You can see recent changes on the evaluation packages, now is well tunned, left joins is just a pain with big tables (our cr_items has about 450K rows), basically we changed to use a tcl "approach" than sql approach and its a lot more faster.

Yes, NOT IN is not optimized, see a recent commit on CR.

Most of our problems where due the interaction with the CR, since is heavily used.

All the changes we have been doing are on CVS now, but most of them where on the evaluation packages, though we fixed stuff on other packages.

For the functions I think they were on the WHERE clause.