Paul J Stevens wrote: > > The relevant quote form the RFC: > > 6.4.4. SEARCH Command > .... > In all search keys that use strings, a message matches the key if > the string is a substring of the field. The matching is > case-insensitive. > .... >
I've been thinking about this a lot and I wonder if this solution makes sense. First, DBMail can try the query that I came up with. If this returns no results use the original query otherwise use the results it returns. This would impose a 15ms penalty on my system when it doesn't work instead of always imposing a 1.5s penalty. For the queries that I've been seeing issued all of them will work with the new query but in order to be compliant with the standards we would leave the original one in. Is that a reasonable tradeoff or would it cause unwanted side effects? I only see it being a problem if someone is doing a search for part of a header like a partial message ID and there happens to be a field that exactly matches that partial message ID substring. It feels like that scenario is unlikely. Tim Mattison -- View this message in context: http://old.nabble.com/Performance-issue-when-copying-moving-messages-in-PostgreSQL-%28IMAP%29-tp26849342p26875617.html Sent from the dbmail dev mailing list archive at Nabble.com. _______________________________________________ Dbmail-dev mailing list [email protected] http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
