You're right Josh, But meanwhile the log table is very usable, having this on a raw file is not good also. So the switch to turn on/off saves your life, and I'm sure that when it'll be implemented the switch will appear in dbmail.conf.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Marshall Sent: terça-feira, 11 de Setembro de 2007 0:29 To: DBMail mailinglist Subject: Re: [Dbmail] Log table All these extra log details - stored in the database - is this going to grow out of control? Would this table be periodically flushed so that it wouldn't end up being bigger than is manageable. As it is our mail server is logging 30-40 lines per second during peak usage. I don't mind this going to a logfile but inserting this into the database is going to make performance suffer unless I put the table on a different disk. It makes no sense to me that for a simple read on the database - e.g. check for mail - needs to correspond with a write to the database for no reason except for statistics that I might read on the rare occasion. At least if the code is written for this please make a switch in the database so that we can turn it off. Sorry for the pessimistic view, just I want to have our servers at peak performance. Josh. >> On Thu, 2007-09-06 at 09:59 +0200, Michael Monnerie wrote: >>> >>> I'd also like a field messages_transferred, mostly for pop, but also >>> possible for imap I guess. >> >> For IMAP it might be nice to know both messages retrieved (or I guess >> message parts, as you don't have to retrieve the whole thing, do you?) >> and messages APPENDed separately. Probably even byte counters for >> up/down would be useful there. _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
