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? http://nfg3.nfgs.net/cgi-bin/gitweb.cgi?p=dbmail.git;a=commitdiff;h=385d26a95b470cbeacd4f0e825976d78a6076ba2 -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl
