Michael, I do get your point: those tables do contain too many duplicate entries. That is because they have a references to the physmessage table. But that relation should probably be changed:
for example, now we have: headername <- headervalue -> physmessage which imposes a 1-1 relation between each physmessage and a full set of records in headervalue. However if we do: headername <- headervalue <- headerlist <- physmessage we can make sure any unique headervalue is never inserted more than once. the same applies for the other caching tables. Paul J Stevens wrote: > Michael Monnerie wrote: >> Wouldn't it be possible to save a lot of space by compressing the >> contents of the various header tables? >> >> dbmail_envelope >> dbmail_headervalues >> dbmail_fromfield >> etc. >> >> They all contain thousands of entries with the same value. In case of >> dbmail_envelope, it's just the date that differs, but all those >> automated e-mails have the same subject etc., that contents could be >> compressed. >> >> It's not about disk space (just a bit), but more about content access >> speed and caching. Having thousands of same entries pollutes the cache, >> and having a DB should help reducing this problem. > > How does compressing those fields help with access speed?? On the > contrary, it will only slow things down. > >> When you're already working on compressing the contents, maybe there's >> an idea for this also? > > I thought about compressing contents while working on SiS, but it won't > happen. > > Also, with SiS, a thousand messages with the same rfc2822 header will > lead to only a single set of entries in the cache tables. > > -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
