On Mon, 2006-06-19 at 22:04 +0200, Paul J Stevens wrote: > Aaron Stone wrote: > >> In any case, I fail to see how this is an issue: if you're using > >> dynamically generated code in performance critical areas of the server > >> you have bigger things to worry about than the overhead of prepared > >> statements. > > > > I'd argue that the sorting code is not performance critical; while it > > sure would be nice to provide instantaneous search results, I think most > > users are aware of how long it can take to find a needle in a haystack. > > I concur. Initial cost are fixed. Search cost are on a scale. We can > deal with initial cost. > > > The really critical areas of code, along the insertion chain and IMAP > > headers and message retrieval, are based on pre-written queries. > > Yep. We should be able to rig an api that will allow us to replace > queries one by one. But I'm working on sqlite atm. About to get it to > pass the unit-tests. Bit of a problem getting the udf code to work on > sqlite3, though. I'm *not* on familiar terms with the sqlite api. Geo?
Just FYI: VACUUM is no longer required in sqlite3- the database can AutoVacuum as necessary. ... and I thought we were stopping the REGEX stuff to take advantage of the indexes where possible? > http://nfg3.nfgs.net/cgi-bin/gitweb.cgi?p=dbmail.git;a=commitdiff;h=385d26a95b470cbeacd4f0e825976d78a6076ba2 Should I be tracking your GIT? I'd be happy to hack together an sqlite3 port, I'd just prefer to start wherever you're at :) -- Internet Connection High Quality Web Hosting http://www.internetconnection.net/
