[Dbmail] OT: DBMail Administrator (DBMA) Performance Fix

2009-04-03 Thread Wallace Tan
I have been using DBMA to administer DBMail v2.2.10 On the home page of DBMA web interface, it displays only the top part of the page. I discovered the issue was due to a slow query in MySQL, after checking the slow-query-log in MySQL. The slow query is: SELECT COUNT(*) FROM dbmail_messageblks;

Re: [Dbmail] OT: DBMail Administrator (DBMA) Performance Fix

2009-04-03 Thread Michael Monnerie
On Freitag 03 April 2009 Wallace Tan wrote: SELECT COUNT(*) FROM dbmail_messageblks; 1 row in set (2 min 18.09 sec) After optimizing the SQL, it took 0.27 seconds. SELECT COUNT(*) FROM dbmail_messageblks use index(physmessage_id_index); The question is: Why is MySQL so stupid not to use the

Re: [Dbmail] OT: DBMail Administrator (DBMA) Performance Fix

2009-04-03 Thread Wallace Tan
Michael Monnerie wrote: The question is: Why is MySQL so stupid not to use the index? That should be done automatically by the DBMS, that's its job. I would oppose against changing the query just because MySQL has a bug. Maybe you use a version that's known to be instable? I am using MySQL

Re: [Dbmail] OT: DBMail Administrator (DBMA) Performance Fix

2009-04-03 Thread Wallace Tan
Wallace Tan wrote: I am using MySQL v5.0.77 MySQL IS using PRIMARY index for the slow query. However, after reading comment 19 at: http://www.mysqlperformanceblog.com/2006/12/01/count-for-innodb-tables/ I got the idea to use another index for the COUNT. Any MySQL experts can explain

Re: [Dbmail] OT: DBMail Administrator (DBMA) Performance Fix

2009-04-03 Thread Michael Monnerie
On Freitag 03 April 2009 Wallace Tan wrote: select count(1) from t1; That would have been my next question. I've spoken once to Paul, because dbmail uses lots of count(*), but PostgreSQL optimizes this out. Now it seems MySQL would have a performance boost using count(1). Could you please

Re: [Dbmail] OT: DBMail Administrator (DBMA) Performance Fix

2009-04-03 Thread Wallace Tan
Michael Monnerie wrote: On Freitag 03 April 2009 Wallace Tan wrote: select count(1) from t1; That would have been my next question. I've spoken once to Paul, because dbmail uses lots of count(*), but PostgreSQL optimizes this out. Now it seems MySQL would have a performance boost using

Re: [Dbmail] OT: DBMail Administrator (DBMA) Performance Fix

2009-04-03 Thread Wallace Tan
Michael Monnerie wrote: On Freitag 03 April 2009 Wallace Tan wrote: select count(1) from t1; That would have been my next question. I've spoken once to Paul, because dbmail uses lots of count(*), but PostgreSQL optimizes this out. Now it seems MySQL would have a performance boost using

Re: [Dbmail] OT: DBMail Administrator (DBMA) Performance Fix

2009-04-03 Thread Josh Berkus
In MySQL (using InnoDB engine) there is no difference for between COUNT(*) or COUNT(1) because it is 'optimized' to use the PRIMARY index. FWIW, there's no difference in PostgreSQL either. --Josh ___ DBmail mailing list DBmail@dbmail.org

Re: [Dbmail] OT: DBMail Administrator (DBMA) Performance Fix

2009-04-03 Thread Michael Monnerie
On Freitag 03 April 2009 Josh Berkus wrote: FWIW, there's no difference in PostgreSQL either. Yes, but the other way round: In PostgreSQL it's always *FAST*. So, a little bit of difference ;-) EXPLAIN ANALYZE SELECT COUNT(*) FROM dbmail_messageblks;

Re: [Dbmail] OT: DBMail Administrator (DBMA) Performance Fix

2009-04-03 Thread Leif Jackson
All, Been a long time since I posted anything but I wanted to give some number for the group as well. Just an FYI it also maybe hardware and version dependent, that is to say that the performance measurements are not cpu bound therefor it may be IO that is saturated which will happen on either

Re: [Dbmail] OT: DBMail Administrator (DBMA) Performance Fix

2009-04-03 Thread Jonathan Feally
Wallace Tan wrote: And what's the best admin interface for DBMail? Not to toot my own horn, but I did up a php based administration tool for managing your mailboxes and aliases along with added functionality to partition your users into manageable groups. See