Comments on: My Innodb Feature wishes http://www.mysqlperformanceblog.com/2006/05/04/my-innodb-feature-wishes/ Everything about MySQL Performance Sat, 21 Nov 2009 05:23:57 -0800 http://wordpress.org/?v=2.8.4 hourly 1 By: Linux Unix » Awesome List of InnoDB (MySQL) Feature Wishes http://www.mysqlperformanceblog.com/2006/05/04/my-innodb-feature-wishes/comment-page-1/#comment-2143 Linux Unix » Awesome List of InnoDB (MySQL) Feature Wishes Fri, 01 Sep 2006 11:54:02 +0000 http://www.mysqlperformanceblog.com/2006/05/04/my-innodb-feature-wishes/#comment-2143 [...] Well, what do you expect from MySQL tuning guru Peter Zaitsev? He spoke at a number of the MySQL User’s Conference sessions. If you use MySQL, you should probably care about this wishlist. The “tablespaces” item does it for me.read more | digg story [...] [...] Well, what do you expect from MySQL tuning guru Peter Zaitsev? He spoke at a number of the MySQL User’s Conference sessions. If you use MySQL, you should probably care about this wishlist. The “tablespaces” item does it for me.read more | digg story [...]

]]> By: peter http://www.mysqlperformanceblog.com/2006/05/04/my-innodb-feature-wishes/comment-page-1/#comment-38 peter Fri, 19 May 2006 23:18:09 +0000 http://www.mysqlperformanceblog.com/2006/05/04/my-innodb-feature-wishes/#comment-38 Dmitry, This is pretty common request which is of high priority as soon as I know. It is however not as trivial as it sounds as Innodb is multi versioning engine so each transaction could see different amount of rows in the table which needs extra handling. Not what it is impossible just not as trivial as you're saying. At this poing if you have no holes in your primary key and it goes from one select max(id) is frequently good and fast way to get the count. You also could use counter table especially now with Triggers in MySQL 5.0 Yes I know it is ugly but we have to live with what we have :) Dmitry,

This is pretty common request which is of high priority as soon as I know. It is however not as trivial as it sounds as Innodb is multi versioning engine so each transaction could see different amount of rows in the table which needs extra handling. Not what it is impossible just not as trivial as you’re saying.

At this poing if you have no holes in your primary key and it goes from one select max(id) is frequently good and fast way to get the count. You also could use counter table especially now with Triggers in MySQL 5.0

Yes I know it is ugly but we have to live with what we have :)

]]> By: Dmitry http://www.mysqlperformanceblog.com/2006/05/04/my-innodb-feature-wishes/comment-page-1/#comment-37 Dmitry Fri, 19 May 2006 20:45:42 +0000 http://www.mysqlperformanceblog.com/2006/05/04/my-innodb-feature-wishes/#comment-37 simple "SELECT COUNT(*) FROM table" takes minutes/hours to run on tables with xxM records, can't InnoDB calculate it based on Primary Key instantly? simple “SELECT COUNT(*) FROM table” takes minutes/hours to run on tables with xxM records, can’t InnoDB calculate it based on Primary Key instantly?

]]> By: peter http://www.mysqlperformanceblog.com/2006/05/04/my-innodb-feature-wishes/comment-page-1/#comment-33 peter Tue, 16 May 2006 00:00:06 +0000 http://www.mysqlperformanceblog.com/2006/05/04/my-innodb-feature-wishes/#comment-33 Gokhan, This bug is actually a bit different even though it also correspond to poor subselect optimization and they have a lot in common. In general it might be better to report similar looking bug as new bug as if it is the same bug it will be quickly checked as soon as bug fixed, if it is not both of them can be fixed and so you will not find out the bug fixed does not apply to your case. Speaking about long time to fix the bug. Yes there is large backlog formed due to the rush with 5.0 development cycle. I hope back backlog will be reduced soon and we'll get back to prompt bug resolution. Gokhan,

This bug is actually a bit different even though it also correspond to poor
subselect optimization and they have a lot in common.

In general it might be better to report similar looking bug as new bug as if it is the same bug it will be quickly checked as soon as bug fixed, if it is not both of them can be fixed and so you will not find out the bug fixed does not apply to your case.

Speaking about long time to fix the bug. Yes there is large backlog formed due to the rush with 5.0 development cycle. I hope back backlog will be reduced soon and we’ll get back to prompt bug resolution.

]]> By: Gokhan Demir http://www.mysqlperformanceblog.com/2006/05/04/my-innodb-feature-wishes/comment-page-1/#comment-31 Gokhan Demir Mon, 15 May 2006 18:16:30 +0000 http://www.mysqlperformanceblog.com/2006/05/04/my-innodb-feature-wishes/#comment-31 Hi Peter, Thanks for the suggestion. Before submitting this case as a bug, I made a search through the bug system and found that bug, most probably very similar to this. http://bugs.mysql.com/bug.php?id=18465 Therefore, I decided not to submit this case as a bug. By the way, especially nowadays, it is getting too much time for mysql developers to fix the bugs. There are even some severity 1 bugs open for six months or so, and no response from MySQL at all. Best Regards, Gokhan Hi Peter,

Thanks for the suggestion. Before submitting this case as a bug, I made a search through the bug system and found that bug, most probably very similar to this.

http://bugs.mysql.com/bug.php?id=18465

Therefore, I decided not to submit this case as a bug.

By the way, especially nowadays, it is getting too much time for mysql developers to fix the bugs. There are even some severity 1 bugs open for six months or so, and no response from MySQL at all.

Best Regards,
Gokhan

]]> By: peter http://www.mysqlperformanceblog.com/2006/05/04/my-innodb-feature-wishes/comment-page-1/#comment-30 peter Mon, 15 May 2006 03:01:09 +0000 http://www.mysqlperformanceblog.com/2006/05/04/my-innodb-feature-wishes/#comment-30 Gokhan, In this case it could be Optimizer bug with subselect execution or with explain. Please report it at http://bugs.mysql.com This query should be using all 3 keyparts but explain shows it does not. Note there are VERY many missing optimizations with Subselects at this point. You should be very careful migrating Subselects from other Database servers as they could run much slower. In your case the best approach perhaps is to think how you can rewrite this query to perform well on MySQL. Gokhan,

In this case it could be Optimizer bug with subselect execution or with explain. Please report it at http://bugs.mysql.com This query should be using all 3 keyparts but explain shows it does not.

Note there are VERY many missing optimizations with Subselects at this point. You should be very careful migrating Subselects from other Database servers as they could run much slower.

In your case the best approach perhaps is to think how you can rewrite this query to perform well on MySQL.

]]> By: Gokhan Demir http://www.mysqlperformanceblog.com/2006/05/04/my-innodb-feature-wishes/comment-page-1/#comment-29 Gokhan Demir Sun, 14 May 2006 10:32:57 +0000 http://www.mysqlperformanceblog.com/2006/05/04/my-innodb-feature-wishes/#comment-29 Why can Sybase use the three columns and MySQL cannot? Why can Sybase use the three columns and MySQL cannot?

]]> By: Gokhan Demir http://www.mysqlperformanceblog.com/2006/05/04/my-innodb-feature-wishes/comment-page-1/#comment-28 Gokhan Demir Sun, 14 May 2006 10:21:16 +0000 http://www.mysqlperformanceblog.com/2006/05/04/my-innodb-feature-wishes/#comment-28 This same test case takes 30 seconds to complete with Sybase ASE 15. Showplan output clearly states the usage of all three columns in the correlated subquery. Now, I have a production system with this kind of select and the data is growing day by day, I don't know what to do. This same test case takes 30 seconds to complete with Sybase ASE 15. Showplan output clearly states the usage of all three columns in the correlated subquery. Now, I have a production system with this kind of select and the data is growing day by day, I don’t know what to do.

]]> By: peter http://www.mysqlperformanceblog.com/2006/05/04/my-innodb-feature-wishes/comment-page-1/#comment-27 peter Sun, 14 May 2006 02:42:09 +0000 http://www.mysqlperformanceblog.com/2006/05/04/my-innodb-feature-wishes/#comment-27 Gokhan, I finally had a time to take a look at your case. I'm not sure what it has to do with Range usage. In your case join can be only performed using two key parts. You can see it in explain as ref: "test.T.cur,const" with "ref" access type. At the stage when Join happens the value for third keypart is not yet avaiable as subselect is not executed. Now if you look at the number of rows query would return without subselect: mysql> select count(*) from Statement T join CurrDailyVal Q on Q.cur1 = T.cur and Q.cur2 = "EUR"; +----------+ | count(*) | +----------+ | 55125114 | +----------+ 1 row in set (1 min 17.06 sec) This subquery will need to be executed 55mi times so do not expect fast answer even if subquery is almost instant :) Gokhan,

I finally had a time to take a look at your case. I’m not sure what it has to do with Range usage. In your case join can be only performed using two key parts. You can see it in explain as ref: “test.T.cur,const” with “ref” access type. At the stage when Join happens the value for third keypart is not yet avaiable as subselect is not executed.

Now if you look at the number of rows query would return without subselect:

mysql> select count(*) from Statement T join CurrDailyVal Q on Q.cur1 = T.cur and Q.cur2 = “EUR”;
+———-+
| count(*) |
+———-+
| 55125114 |
+———-+
1 row in set (1 min 17.06 sec)

This subquery will need to be executed 55mi times so do not expect fast answer even if subquery is almost instant :)

]]> By: Gokhan Demir http://www.mysqlperformanceblog.com/2006/05/04/my-innodb-feature-wishes/comment-page-1/#comment-24 Gokhan Demir Wed, 10 May 2006 19:24:41 +0000 http://www.mysqlperformanceblog.com/2006/05/04/my-innodb-feature-wishes/#comment-24 According to the documentation at MySQL site, Peter is right. MySQL should use all three columns in the inner select. However, I have faced performance problems in the real world which made me think MySQL does not use the range indexes efficiently. For the example query I previously attached here, I have prepared a test case, where you can see what I mean. To better illustrate what I mean, I have put rather big amounts of data to both tables. Statement table has 172806 rows, and CurrDailyVal has 638 rows. You can download the test case at http://igonline.biz/gdemir/data.tar.bz2 and try for yourself. The test case file itself is 1367455 bytes (~1.3 MB). According to the documentation at MySQL site, Peter is right. MySQL should use all three columns in the inner select. However, I have faced performance problems in the real world which made me think MySQL does not use the range indexes efficiently.

For the example query I previously attached here, I have prepared a test case, where you can see what I mean. To better illustrate what I mean, I have put rather big amounts of data to both tables. Statement table has 172806 rows, and CurrDailyVal has 638 rows. You can download the test case at http://igonline.biz/gdemir/data.tar.bz2 and try for yourself. The test case file itself is 1367455 bytes (~1.3 MB).

]]>