On 26-02-14 20:58, Gray, Patrick wrote:
> Would something like:
> Delete from dbmail_headervalues where id not in(select headervalue_id from
> dbmail_header);
That situation should never occur if your schema is intact, since
dbmail_header.headervalue_id references dbmail_headervalue.id with a
cascading foreign key constraint.
What I was referring to is the situation where dbmail currently caches
every mime-header in every email message separately. It doesn't cache
headers of enclosed attachments - but still, it caches way too much at
the moment.
Mind you the cache is only needed for imap-search, which is used by
dbmail-imapd of course, and also by dbmail-export - which allows you to
filter the export using a imap-search query. And such searches typically
use a limited set of headers, most, if not just about 100% of the time.
The new feature in the master tree allows you to just say '*enough
already*,I know which headers I want to cache, so heel, dog!'. No more
new rows in dbmail_headernames, and any headername that is unknown is
simply ignored during message indexing. This will allow admins to tune
the 'index' of headers. Need to cache a certain header in your use-case,
say 'X-Funky-Data-Index'? Just insert it into dbmail_headernames manually.
In more advanced full-text search engines such as SOLR you need to
specify which data you wish to index explicitly. DBMail should allow the
same.
--
________________________________________________________________
Paul J Stevens pjstevns @ gmail, twitter, github, linkedin
www.nfg.nl/i...@nfg.nl/+31.85.877.99.97
_______________________________________________
DBmail mailing list
DBmail@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
