timmattison wrote: > > 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.
I would suggest another approach: begin; drop index dbmail_headervalue_3; alter table dbmail_headervalue alter headervalue type varchar(255) not null default ''; create index dbmail_headervalue_3 on dbmail_headervalue(headervalue); commit; that way, you can leave the code as-is. Of course, above statements will fail if there are headervalues longer than 255, so you might have to tweak the alter table statement to truncate longer values. And this truncation implies that some searches will no longer return some messages, which is why this can't be the standard. But searches will be much faster. Maybe, the headervalue table should be split-up into headervalues shorter than 255, and values longer than 255 bytes.... -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl _______________________________________________ Dbmail-dev mailing list [email protected] http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
