Mikhail Ramendik <[EMAIL PROTECTED]> said: > 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.
Oh, cool. So that I don't have to go digging in the archives, would you be able to post the latest versions of these to your website? [snip] > 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. I think that 2.1 should require MySQL 4.1, which means sub-selects and transactions can become an integral part of our queries. [snip] > 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. If we can't get three header tables in 2.1, then I'll settle for two ;-) We've had big partial rewrites already, and experience shows that they can take up to a year each. This is to be expected, I think. > 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. We could make this change during 2.0.x, actually. It's only code and queries that are changing, not the database structure or other user interfaces. Aaron --
