Aaron Stone wrote: > I haven't read the patch over yet, but I think Paul has (?). Wasn't there > a thread about Firebird and/or Outlook problems with this or another > patch? Let's make sure that all of those are resolved.
This was with the CVS HEAD version. My existing speedup was intended for 2.0.x only, and so the patch is against 2.0 not CVS HEAD, and the changes are minimal. > > For 2.1 I'm planning a bigger change, although I'm not yet sure it will > > work out in the current code framework. I also have an idea for a SEARCH > > speedup in 2.1. > > Paul has a lot of time invested into his ic_fetch refactoring for 2.1, so > while some duplication of effort may help you to understand the code > better, if there's another project you'd like to put some time into, that > would probably be better. Actually the change is planned *afper* Paul's refactoring; I'll wait for Paul's code to get tested/stabilized a bit and then (hopefully) try a speedup. Or perhaps Paul will port my current speedup to CVS HEAD and I'll work on top of that. Actually there are questions for the 2.1 speedup - basically, how far are we willing to go with changing the database interface in 2.1. The "maximum" variant involves using a big query instead of many small ones, but at least for mysql this means a whole set of new/changed db basic API functions, to enable the use of mysql_use_query instead of mysql_set_query for this. I'm not sure about pgsql yet. But the existing version is far less invasive. > Speeding up SEARCH would be great; our current plans for that include a > "fastheaders" table set that has the header names in one table and a > relation/value table with the message id, header id and header value. > There hasn't been any work on this yet, so if you have another idea we're > all ears. Actually I have two ideas on SEARCH. One is a change in header storage, similar to what you described (involving three tables instead of two, but this is a technical detail that can be worked out later). But I'm not sure this will work for 2.1, that is, before a BIG partial rewrite that is certainly needed (the language is another question) and is going to be -ng or 3.0. But I also have a simpler idea that will still speed things up. It involves using a regexp SQL fulltext search. While it's definitely slow compared to a changed storage (the db won't be able to use indexes), it's still faster because it does not involve any parsing, and uses the well-tuned SQL server code to do fulltext searching. The advantage is that it will work on current storage (with is_header), and therefore can be a better interim solution for 2.1, befire a new storage layout is fully supported. Yours, Mikhail Ramendik
