Jonathan Feally wrote: > The emailaddr column is used for sorting only. The headervalue column is > what is used for the where clauses.
Jon, in your latest code, the emailaddr/emailname columns are never used again after insertion. We really shouldn't be storing information that is not used, especially when they are blobs. Also, the sortfield is a blob/text field but stored as a string. That is incorrect. It should use the libzdb blob interfaces, like done for headervalue. But read on below. In fact, I'm starting to believe we should simply drop the emailaddr/emailname cache columns, and rely on headervalue and sortfield. > So the only column that needs to be > worried about for the index containing the data is the headervalue. In > most cases a 255 byte index on the emailaddr column would be sufficient > for sorting messages on the server side. The emailname is just there for > future use. We cannot split the recipients into multiple rows as that > would break the imap sort back to way it was where some messages could > be sorted in a different order than the rfc permits. We should truncate the sortfield to 255 characters, change it to a varchar(255) and do full width indexing. Using the first 255 characters of a field to sort seems like sufficient for the forseable future. Do we really want to be able to sort on longer headers? -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl _______________________________________________ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
