[MDEV-5255] SELECT is 2-3x slower when used as source for other construct Created: 2013-11-07 Updated: 2014-10-02 Resolved: 2014-10-02 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Storage Engine - TokuDB |
| Affects Version/s: | 5.5.33a, 10.0.13 |
| Fix Version/s: | 5.5.40, 10.0.14 |
| Type: | Bug | Priority: | Minor |
| Reporter: | Ján Regeš | Assignee: | Sergei Golubchik |
| Resolution: | Fixed | Votes: | 1 |
| Labels: | performance, tokudb, upstream | ||
| Environment: |
MariaDB 5.5.33a with TokuDB support |
||
| Description |
|
Hi. I'm using TokuDB tables with COMPRESSION=tokudb_small. MariaDB 5.5.33a with TokuDB support. Builded from amd64 sources with cmake. I have one SELECT, which returns about 100 records with 20 number columns. These records are aggregated from 1 mio records in 3 joined tables, by indexed columns. It's relatively simple, with predictable and clean execution plan. This select is running stable about 4,8 seconds. I use SQL_NO_CACHE flag. But, when this same SELECT is part of any other simple construct (for example CREATE TABLE [select], or INSERT INTO [select] ON DUPLICATE KEY UPDATE), this query is running 2-3x slower, about 13 seconds. In query profile, or status, there are identical informations (Handler_read_key, etc.) for both usages. But with one important difference - durations of query steps:
So, when SELECT is part of other construct, this select is about 2-3x slower. Just for sure, i used also index-hinting for every joined table. These hints are the same, which EXPLAIN reports. So, execution plan is same in both usages. I used also "SQL_NO_CACHE" flag, for securing identical environment. SELECT returns just 100 records, so, there is no big related overhead with creating new temporary table, or inserting/updating rows. When this SELECT is vestured in other SELECT * FROM [select] LIMIT 1, result is the same. Do you know about this performance issue? Thank you.
|
| Comments |
| Comment by Patryk Pomykalski [ 2013-11-07 ] |
|
This one states slower updates and deletes, but maybe it's the same issue (disabled bulk fetching): |
| Comment by Sergei Golubchik [ 2013-11-19 ] |
|
Right, it's https://github.com/Tokutek/ft-engine/issues/143 — bulk fetching is not used where it could've been. |
| Comment by Rich Prohaska [ 2014-07-18 ] |
|
Fixed in tokudb-7.1.8. |
| Comment by Ján Regeš [ 2014-07-18 ] |
|
Thank you! TokuDB 7.1.8 will be released about 08/2014? |
| Comment by Rich Prohaska [ 2014-07-24 ] |
|
We have some partial code (on our github tokudb-7.1.8-rc4 branch) that we are testing. We also are investigating a few other situations where bulk fetch may be used. The target for release is middle sept 2014. |
| Comment by Sergei Golubchik [ 2014-10-02 ] |
|
the fix was pulled in with TokuDB 7.5.0 |
| Comment by Ján Regeš [ 2014-10-02 ] |
|
Thank you, Sergei :-* |