<?xml version="1.0" encoding="iso-8859-1" ?>
<?xml-stylesheet title="XSL_formatting" type="text/xsl" href="/images/lists/rssstyle2.xsl"?>
<rss version="2.0">
<channel>
<title>DBMail | users</title>
<description>Mailing List Archive by Gossamer Threads</description>
<link>http://www.gossamer-threads.com/lists/dbmail/users/</link>
<language>en-us</language>
<copyright>(c) Gossamer Threads Inc. All rights reserved.</copyright>
<lastBuildDate>16 May  2008 19:21:23 -0800</lastBuildDate>
<ttl>120</ttl>
<image>
<title>Gossamer Threads | DBMail | users</title>
<width>75</width>
<height>23</height>
<link>http://www.gossamer-threads.com/lists/dbmail/users/</link>
<url>http://www.gossamer-threads.com/images/lists/rss_logo.jpg</url>
</image>
<item>
<title>Re: DBMAIL grinds to a craw in production</title>
<description>Also make sure that your MySQL is not 5.1.23 from packages or ports. I had an issue with the sorting of large result sets losing rows. I had the iss</description>
<pubDate>16 May  2008 17:58:37 -0800</pubDate>
<link>http://www.gossamer-threads.com/lists/dbmail/users/25453</link>
</item><item>
<title>What happened to dbmail admin website?</title>
<description>Hi Everyone, Does anyone know what has happened to the dbmail admin website - http://dbma.mobrien.com ? It seems to have been down for at least a co</description>
<pubDate>16 May  2008 17:14:18 -0800</pubDate>
<link>http://www.gossamer-threads.com/lists/dbmail/users/25452</link>
</item><item>
<title>Re: DBMAIL grinds to a craw in production</title>
<description>Thanks Jon and all others for your great suggestions. As Jon said, I&amp;#039;m drawing towards the conclusion that the issue was with some bug or incompatibi</description>
<pubDate>16 May  2008 09:06:03 -0800</pubDate>
<link>http://www.gossamer-threads.com/lists/dbmail/users/25451</link>
</item><item>
<title>Re: DBMAIL grinds to a craw in production</title>
<description>&amp;gt; I&amp;#039;m not 100% sure, but I think these are MyISAM only. I think the &amp;gt; roughly equivalent InnoDB setting is: &amp;gt; &amp;gt; innodb_buffer_pool = 1024M It is myis</description>
<pubDate>16 May  2008 03:16:36 -0800</pubDate>
<link>http://www.gossamer-threads.com/lists/dbmail/users/25450</link>
</item><item>
<title>RE: user login with domain suffix</title>
<description>Hi,  I&amp;#039;ve written a patch for pop3 and imap to rewrite usernames similar to this request, it reduced support emails/calls/tickets by 25% :P. Perhaps</description>
<pubDate>15 May  2008 15:46:57 -0800</pubDate>
<link>http://www.gossamer-threads.com/lists/dbmail/users/25449</link>
</item><item>
<title>user login with domain suffix</title>
<description>Hi all. Thanks for all your suggestions on my last question. Now I have another question. Is there a way to specify dbmail pop/imap to ignore domain</description>
<pubDate>15 May  2008 15:23:51 -0800</pubDate>
<link>http://www.gossamer-threads.com/lists/dbmail/users/25448</link>
</item><item>
<title>RE: Exporting users from DBMail to Postfix lookup table</title>
<description>You could prolly use centos 5 version of postfix what comes with mysql and pgsql support. RHEL5 is based to FC6 and centos5 = rhel5 Same time you cou</description>
<pubDate>15 May  2008 14:30:22 -0800</pubDate>
<link>http://www.gossamer-threads.com/lists/dbmail/users/25447</link>
</item><item>
<title>Re: LDAP / dbmailDomain</title>
<description>James, my earlier post illustrates how the dbmailDomain objectClass might by of use. There is no &amp;#039;supposed-to&amp;#039; in the ldap world. It is strictly a co</description>
<pubDate>15 May  2008 09:36:08 -0800</pubDate>
<link>http://www.gossamer-threads.com/lists/dbmail/users/25443</link>
</item><item>
<title>LDAP / dbmailDomain</title>
<description>Hi Everyone,   Could someone please explain to me how to the LDAP dbmailDomain object class is supposed to work?   &amp;gt;From what I can see, it is des</description>
<pubDate>15 May  2008 05:19:41 -0800</pubDate>
<link>http://www.gossamer-threads.com/lists/dbmail/users/25441</link>
</item><item>
<title>Re: One more word on database performance</title>
<description>On Wed, 2008-05-14 at 14:14 +0200, Daniel Urstöger wrote: &amp;gt; &amp;gt; &amp;gt; &amp;gt; On Wed, 2008-05-14 at 13:32 +0200, Michael Mayer wrote: &amp;gt; &amp;gt; &amp;gt; &amp;gt; &amp;gt; But who could h</description>
<pubDate>14 May  2008 22:48:49 -0800</pubDate>
<link>http://www.gossamer-threads.com/lists/dbmail/users/25439</link>
</item><item>
<title>Re: DBMAIL grinds to a craw in production</title>
<description>Do Not use Mysql 5.1.23-rc on FreeBSD from ports/packages!!! Use 5.1.22. I ran into an issue where order by&amp;#039;s were causing data from the result sets</description>
<pubDate>14 May  2008 22:39:53 -0800</pubDate>
<link>http://www.gossamer-threads.com/lists/dbmail/users/25438</link>
</item><item>
<title>Re: Re: messages table index brainstorming</title>
<description>Michael Mayer wrote: &amp;gt; Paul J Stevens wrote: &amp;gt;&amp;gt;  formail -ds dbmail-smtp -u testuser$i -m mailbox$j &amp;gt; &amp;gt; Do I have to add those 100 testusers and ma</description>
<pubDate>14 May  2008 14:06:28 -0800</pubDate>
<link>http://www.gossamer-threads.com/lists/dbmail/users/25436</link>
</item><item>
<title>Re: Re: messages table index brainstorming</title>
<description>Paul J Stevens wrote: &amp;gt;  formail -ds dbmail-smtp -u testuser$i -m mailbox$j Do I have to add those 100 testusers and mailboxes first or will that</description>
<pubDate>14 May  2008 12:20:11 -0800</pubDate>
<link>http://www.gossamer-threads.com/lists/dbmail/users/25435</link>
</item><item>
<title>Re: Re: messages table index brainstorming</title>
<description>Michael Mayer wrote: &amp;gt; dbmail@bobich.net wrote: &amp;gt;&amp;gt; But if you can empirically demonstrate that over-indexing &amp;gt;&amp;gt; signifficantly slows down the typical</description>
<pubDate>14 May  2008 11:32:21 -0800</pubDate>
<link>http://www.gossamer-threads.com/lists/dbmail/users/25434</link>
</item><item>
<title>Re: Re: messages table index brainstorming</title>
<description>I wish this came up 3 weeks ago. Just before I migrated to dbmail, I purged all of my spam - all 2GB of it (100K-150K messages, IIRC). I figured the</description>
<pubDate>14 May  2008 09:42:15 -0800</pubDate>
<link>http://www.gossamer-threads.com/lists/dbmail/users/25433</link>
</item><item>
<title>Re: Re: messages table index brainstorming</title>
<description>dbmail@bobich.net wrote: &amp;gt; But if you can empirically demonstrate that over-indexing signifficantly &amp;gt; slows down the typical (mostly read) workload o</description>
<pubDate>14 May  2008 09:36:41 -0800</pubDate>
<link>http://www.gossamer-threads.com/lists/dbmail/users/25432</link>
</item><item>
<title>Re: Re: messages table index brainstorming</title>
<description>On Wed, 14 May 2008, Michael Mayer wrote: &amp;gt; In contrast, storing the messages in a very ineffectively clustered way, like &amp;gt; it currently seems to be</description>
<pubDate>14 May  2008 05:28:13 -0800</pubDate>
<link>http://www.gossamer-threads.com/lists/dbmail/users/25429</link>
</item><item>
<title>Re: Re: messages table index brainstorming</title>
<description>dbmail@bobich.net wrote: &amp;gt; I&amp;#039;m still not convinced that over-indexing is harmful in this case. In &amp;gt; general, too many indices is better than too few,</description>
<pubDate>14 May  2008 05:17:01 -0800</pubDate>
<link>http://www.gossamer-threads.com/lists/dbmail/users/25428</link>
</item><item>
<title>Re: One more word on database performance</title>
<description>&amp;gt; &amp;gt; On Wed, 2008-05-14 at 13:32 +0200, Michael Mayer wrote: &amp;gt; &amp;gt;&amp;gt; But who could have such a large mailbox? Anyone here on this list?  &amp;gt;&amp;gt; Then, &amp;gt;&amp;gt; you</description>
<pubDate>14 May  2008 05:14:32 -0800</pubDate>
<link>http://www.gossamer-threads.com/lists/dbmail/users/25427</link>
</item><item>
<title>Re: One more word on database performance</title>
<description>On Wed, 2008-05-14 at 13:32 +0200, Michael Mayer wrote: &amp;gt; But who could have such a large mailbox? Anyone here on this list? Then, &amp;gt; you should thin</description>
<pubDate>14 May  2008 05:06:13 -0800</pubDate>
<link>http://www.gossamer-threads.com/lists/dbmail/users/25426</link>
</item><item>
<title>Re: Re: messages table index brainstorming</title>
<description>I&amp;#039;m still not convinced that over-indexing is harmful in this case. In general, too many indices is better than too few, and even if the data fits i</description>
<pubDate>14 May  2008 04:57:17 -0800</pubDate>
<link>http://www.gossamer-threads.com/lists/dbmail/users/25425</link>
</item><item>
<title>Re: messages table index brainstorming</title>
<description>Michael Mayer wrote: &amp;gt; An interesting idea for performance improvement of the messages table &amp;gt; would be a PRIMARY KEY consisting of mailbox_idnr and</description>
<pubDate>14 May  2008 04:50:34 -0800</pubDate>
<link>http://www.gossamer-threads.com/lists/dbmail/users/25424</link>
</item><item>
<title>One more word on database performance</title>
<description>Hi there, one more word on database performance: If you got an index on the mailbox id and the data is even clustered, then most of the other index</description>
<pubDate>14 May  2008 04:32:09 -0800</pubDate>
<link>http://www.gossamer-threads.com/lists/dbmail/users/25423</link>
</item><item>
<title>messages table index brainstorming</title>
<description>Paul J Stevens wrote: &amp;gt; Michael Mayer wrote: &amp;gt;&amp;gt; But especially the messages &amp;gt;&amp;gt; table seems to be over-indexed. &amp;gt; &amp;gt; Please propose a better index setu</description>
<pubDate>14 May  2008 04:06:18 -0800</pubDate>
<link>http://www.gossamer-threads.com/lists/dbmail/users/25422</link>
</item><item>
<title>Re: Repairing envelope cache generates double entries</title>
<description>Aaron Stone wrote: &amp;gt;&amp;gt; the imap parser is already hooked up into dbmail-export. Shouldn&amp;#039;t be &amp;gt;&amp;gt; too hard to do the same for dbmail-smtp/dbmail-deliver</description>
<pubDate>14 May  2008 01:07:21 -0800</pubDate>
<link>http://www.gossamer-threads.com/lists/dbmail/users/25421</link>
</item>
</channel>
</rss>
