Aaron Stone wrote:
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.
My split-up and reorganization of ic_fetch returns requested items in a fixed order, as opposed to the
requested order like before. My guess is that outlook doesn't like this very much. I can't investigate today
however, since my xp box's terminal-server is dead, and I don't have physical access atm.
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.
I've ported the icfetch_speedup to cvs-head. No commit yet.
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.
But then we first have to make sure we play nicely with 4.1 to begin with.
If we can't get three header tables in 2.1, then I'll settle for two ;-)
What's wrong with *one* extra table like someone else suggested:
(physmessage_id, header-name, header-value) ?
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.
All we need is a voluteer willing to tackle this issue :-)
--
________________________________________________________________
Paul Stevens mailto:[EMAIL PROTECTED]
NET FACILITIES GROUP PGP: finger [EMAIL PROTECTED]
The Netherlands________________________________http://www.nfg.nl
