Comments on: getting rid of duplicate emails, elegantly http://www.flamingspork.com/blog/2006/04/01/getting-rid-of-duplicate-emails-elegantly/ Ramblings which occasionally resemble reality. This is the blog of Stewart Smith. Tue, 06 Jan 2009 01:11:58 +0000 http://wordpress.org/?v=2.7 hourly 1 By: MacPlusG3 http://www.flamingspork.com/blog/2006/04/01/getting-rid-of-duplicate-emails-elegantly/comment-page-1/#comment-27892 MacPlusG3 Tue, 04 Apr 2006 03:38:21 +0000 http://www.flamingspork.com/blog/2006/04/01/getting-rid-of-duplicate-emails-elegantly/#comment-27892 Basically what I'm looking at is to have an external program be able to do the syncing (so you can do updates on disconnected computers and then resync them. So I wouldn't be using the binary log for that. Although I intend to use it to have a replication slave as a backup. I am more tempted to link into Beagle than rely on fulltext indexing at the moment - at least until fulltext is supported across storage engines (and since i may be doing some of the coding for that, i'll be an early adopter too). I'd also present an IMAP interface to the DB, otherwise it's kinda silly. Personally I wouldn't wory about message size or size of table - you just need some optimisations to get better performance! Mail clients such as Evolution keep their own indexes anyway. Since my mail chews up gigabytes as it is, I'm not too concerned about disk space usage. Disk is cheap - loosing data due to deleted emails is not. Basically what I’m looking at is to have an external program be able to do the syncing (so you can do updates on disconnected computers and then resync them. So I wouldn’t be using the binary log for that.

Although I intend to use it to have a replication slave as a backup.

I am more tempted to link into Beagle than rely on fulltext indexing at the moment - at least until fulltext is supported across storage engines (and since i may be doing some of the coding for that, i’ll be an early adopter too).

I’d also present an IMAP interface to the DB, otherwise it’s kinda silly.

Personally I wouldn’t wory about message size or size of table - you just need some optimisations to get better performance!

Mail clients such as Evolution keep their own indexes anyway.

Since my mail chews up gigabytes as it is, I’m not too concerned about disk space usage.

Disk is cheap - loosing data due to deleted emails is not.

]]> By: Sheeri http://www.flamingspork.com/blog/2006/04/01/getting-rid-of-duplicate-emails-elegantly/comment-page-1/#comment-27878 Sheeri Mon, 03 Apr 2006 16:46:22 +0000 http://www.flamingspork.com/blog/2006/04/01/getting-rid-of-duplicate-emails-elegantly/#comment-27878 We have a database solution for mail in our system, and we actually want to move to IMAP. Partially because of features, and partially because of problems we encounter. Basically, FULLTEXT searching only works with MyISAM tables, but we need the row-level locking capabilites of InnoDB. Also, binary logging is impossible, because they would grow large. We currently have limits on message size and how long they're kept for. Make sure you monitor the InnoDB free space as well (or use autoextend and monitor disk usage). We have a database solution for mail in our system, and we actually want to move to IMAP. Partially because of features, and partially because of problems we encounter.

Basically, FULLTEXT searching only works with MyISAM tables, but we need the row-level locking capabilites of InnoDB. Also, binary logging is impossible, because they would grow large. We currently have limits on message size and how long they’re kept for. Make sure you monitor the InnoDB free space as well (or use autoextend and monitor disk usage).

]]>