My guess is that sort is not the bottleneck but 'fetch'. Sort is already fully optimized using only well normalized tables and pretty fast queries.
At this moment envelope and bodystructure still require full message retrieval and parsing. Envelope could be fixed by using the header tables, but both can be fixed by pre-caching the envelope and bodystructure responses like we do already for the headers. Both are so common, and so expensive that it makes a lot of sense. However, doing that while the fetch code is being rebuild seems rather premature. In short, this is on the todo. Aaron Stone wrote: > SM is definitely a big downstream application that we should do > performance profiling with. Matt, if you could post a loglevel 5 trace > that contains the SORT commands that SM send, we can put the command > through the ringer. > > Aaron > > On Mon, 2006-05-15 at 12:26 -0400, Matthew T. O'Connor wrote: > >>Hello all. One of the things I have been hoping to be true about the >>development branch of DBMail is that Squirrelmail would be faster. I >>thought that with the server side sorting and threading that it would >>make a big difference, but so far in my limited testing, I'm not seeing >>any real noticeable improvement. At this point I think it might be a >>configuration issue, but I did set SM for server side sorting etc... >> >>Any advice on SM performance issues with 2.1? Anyone seeing anything >>different? >> >>BTW, This is CentOS 4.3 with PostgreSQL 8.1 and Squirrelmail 1.4.6. >> >>Matt >>_______________________________________________ >>Dbmail-dev mailing list >>[email protected] >>http://twister.fastxs.net/mailman/listinfo/dbmail-dev > > > _______________________________________________ > Dbmail-dev mailing list > [email protected] > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl
