Comments on: Top 5 Wishes for MySQL http://www.mysqlperformanceblog.com/2007/06/29/top-5-wishes-for-mysql/ Everything about MySQL Performance Wed, 17 Mar 2010 18:15:22 +0000 hourly 1 By: Return of the “Top 5 MySQL Wishlist” and looking at Drizzle | Ramblings http://www.mysqlperformanceblog.com/2007/06/29/top-5-wishes-for-mysql/comment-page-1/#comment-664737 Return of the “Top 5 MySQL Wishlist” and looking at Drizzle | Ramblings Wed, 14 Oct 2009 05:27:19 +0000 http://www.mysqlperformanceblog.com/2007/06/29/top-5-wishes-for-mysql/#comment-664737 [...] PeterZ’s view is always interesting, and he had one too: [...] [...] PeterZ’s view is always interesting, and he had one too: [...]

]]> By: no need http://www.mysqlperformanceblog.com/2007/06/29/top-5-wishes-for-mysql/comment-page-1/#comment-336293 no need Mon, 28 Jul 2008 18:51:25 +0000 http://www.mysqlperformanceblog.com/2007/06/29/top-5-wishes-for-mysql/#comment-336293 I wish MySQL would just GO AWAY. They have set the tech landscape back 10 years with their warped and defective product. I wish MySQL would just GO AWAY. They have set the tech landscape back 10 years with their warped and defective product.

]]> By: chad http://www.mysqlperformanceblog.com/2007/06/29/top-5-wishes-for-mysql/comment-page-1/#comment-230992 chad Tue, 15 Jan 2008 02:50:48 +0000 http://www.mysqlperformanceblog.com/2007/06/29/top-5-wishes-for-mysql/#comment-230992 I am glad that you spell these out. I came from Oracle and SQL Server background, where parallel query and partition give you the performance for multiple CPUs and fast IO system. I have spent some time trying to figure out how to drive up performance for large Data warehouse with 16 CPU cores with MySQL. Now I realize that MySQL is just not there in terms of parallel queries, which are so fundimental to ETL process and OLAP processing. Hope MySQL catch up with Oracle and SQL Server soon. Love to know any tricks to speed things up... I am glad that you spell these out. I came from Oracle and SQL Server background, where parallel query and partition give you the performance for multiple CPUs and fast IO system. I have spent some time trying to figure out how to drive up performance for large Data warehouse with 16 CPU cores with MySQL. Now I realize that MySQL is just not there in terms of parallel queries, which are so fundimental to ETL process and OLAP processing. Hope MySQL catch up with Oracle and SQL Server soon. Love to know any tricks to speed things up…

]]> By: Angry UNIXoid’s Humble Abode / MySQL features I would kill for. http://www.mysqlperformanceblog.com/2007/06/29/top-5-wishes-for-mysql/comment-page-1/#comment-151956 Angry UNIXoid’s Humble Abode / MySQL features I would kill for. Tue, 31 Jul 2007 16:43:47 +0000 http://www.mysqlperformanceblog.com/2007/06/29/top-5-wishes-for-mysql/#comment-151956 [...] I want software X to have”. I have seen at least two such posts about MySQL, here and here. So, since I have been working with MySQL for a while, here is my [...] [...] I want software X to have”. I have seen at least two such posts about MySQL, here and here. So, since I have been working with MySQL for a while, here is my [...]

]]> By: Log buffer 52 - a carnival of the vanities for dbas « OraStory http://www.mysqlperformanceblog.com/2007/06/29/top-5-wishes-for-mysql/comment-page-1/#comment-143125 Log buffer 52 - a carnival of the vanities for dbas « OraStory Fri, 06 Jul 2007 18:41:56 +0000 http://www.mysqlperformanceblog.com/2007/06/29/top-5-wishes-for-mysql/#comment-143125 [...] up for the latest Open Source Convention - OSCON 2007 in a couple of weeks. Peter Zeitsev lists his top 5 wishes for mySQL. It’s always good to hear about approaches to familiar problems across different databases [...] [...] up for the latest Open Source Convention – OSCON 2007 in a couple of weeks. Peter Zeitsev lists his top 5 wishes for mySQL. It’s always good to hear about approaches to familiar problems across different databases [...]

]]> By: James Day http://www.mysqlperformanceblog.com/2007/06/29/top-5-wishes-for-mysql/comment-page-1/#comment-141818 James Day Mon, 02 Jul 2007 07:55:28 +0000 http://www.mysqlperformanceblog.com/2007/06/29/top-5-wishes-for-mysql/#comment-141818 Bugs introduced with 4.1 and 5.0 features are still slowing MySQL down. The backlog of increasingly rarely encountered bugs is gradually being cleared up, so MySQL should gradually start to release more quickly. Not as quickly as we might like, but it's happening. Hopefully the QA lessons will also help to make the future releases more reliable more quickly. For a scale-out in a box solution, look at MySQL Proxy as part of the package. Bugs introduced with 4.1 and 5.0 features are still slowing MySQL down. The backlog of increasingly rarely encountered bugs is gradually being cleared up, so MySQL should gradually start to release more quickly. Not as quickly as we might like, but it’s happening. Hopefully the QA lessons will also help to make the future releases more reliable more quickly.

For a scale-out in a box solution, look at MySQL Proxy as part of the package.

]]> By: jcole’s weblog: Jeremy Cole’s take on life. » Blog Archive » My top 5 wishes for MySQL http://www.mysqlperformanceblog.com/2007/06/29/top-5-wishes-for-mysql/comment-page-1/#comment-141387 jcole’s weblog: Jeremy Cole’s take on life. » Blog Archive » My top 5 wishes for MySQL Sat, 30 Jun 2007 20:29:50 +0000 http://www.mysqlperformanceblog.com/2007/06/29/top-5-wishes-for-mysql/#comment-141387 [...] Antony Curtis finally gave in, and Paul McCullagh and Peter Zaitsev also got in on [...] [...] Antony Curtis finally gave in, and Paul McCullagh and Peter Zaitsev also got in on [...]

]]> By: peter http://www.mysqlperformanceblog.com/2007/06/29/top-5-wishes-for-mysql/comment-page-1/#comment-141218 peter Sat, 30 Jun 2007 08:48:35 +0000 http://www.mysqlperformanceblog.com/2007/06/29/top-5-wishes-for-mysql/#comment-141218 Randy, What you're mention is a bug which could be addressed pretty quickly. You may argue some bugs take really long time to fix now after you report them with repeatable test case but that is over story. I mainly mean not small bugs, which are easy to fix but major issues which require significant extra developed to be addressed. The bugs are of course also painful and especially 5.0 was rather buggy in its early production releases Randy,

What you’re mention is a bug which could be addressed pretty quickly. You may argue some bugs take really long time to fix now after you report them with repeatable test case but that is over story.

I mainly mean not small bugs, which are easy to fix but major issues which require significant extra developed to be addressed. The bugs are of course also painful and especially 5.0 was rather buggy in its early production releases

]]> By: Randy http://www.mysqlperformanceblog.com/2007/06/29/top-5-wishes-for-mysql/comment-page-1/#comment-141034 Randy Fri, 29 Jun 2007 23:56:07 +0000 http://www.mysqlperformanceblog.com/2007/06/29/top-5-wishes-for-mysql/#comment-141034 I third the "Be solid" comment. I can't count the number of times the last_insert_id() function hasn't worked properly. It's broke at least three times in version 5 alone. I third the “Be solid” comment. I can’t count the number of times the last_insert_id() function hasn’t worked properly. It’s broke at least three times in version 5 alone.

]]> By: Kilroy http://www.mysqlperformanceblog.com/2007/06/29/top-5-wishes-for-mysql/comment-page-1/#comment-141032 Kilroy Fri, 29 Jun 2007 23:26:13 +0000 http://www.mysqlperformanceblog.com/2007/06/29/top-5-wishes-for-mysql/#comment-141032 I'd like to second that regarding "Be Solid". When I started using MySQL ten years ago, I defended it with, "It doesn't do everything, but what it does it does REALLY WELL." Nowadays when I see a new feature, I usually cringe when I read about its limitations, and many of those limitations, once documented, never get addressed. (Or I don't notice that they do, since I never started using it.) It has made MySQL a much more difficult product to use, because there are pitfalls everywhere. Perhaps if they can get real participation from the volunteer community that will help. They have good people there, and I know they want their product to be good, so it's probably just a manpower problem. (They say they're going to switch away from BitKeeper someday; I expect community involvement to improve at that point.) Anyway, if they could get back to the idea of only deploying a feature if they can do so in a way that doesn't just work for the narrowest of uses, that would be wonderful. Thanks for the great blog! I’d like to second that regarding “Be Solid”. When I started using MySQL ten years ago, I defended it with, “It doesn’t do everything, but what it does it does REALLY WELL.”

Nowadays when I see a new feature, I usually cringe when I read about its limitations, and many of those limitations, once documented, never get addressed. (Or I don’t notice that they do, since I never started using it.) It has made MySQL a much more difficult product to use, because there are pitfalls everywhere.

Perhaps if they can get real participation from the volunteer community that will help. They have good people there, and I know they want their product to be good, so it’s probably just a manpower problem. (They say they’re going to switch away from BitKeeper someday; I expect community involvement to improve at that point.)

Anyway, if they could get back to the idea of only deploying a feature if they can do so in a way that doesn’t just work for the narrowest of uses, that would be wonderful.

Thanks for the great blog!

]]>