[MCOL-681] Inconsistent result set when optimizer uses aira temp table (group by in sub-select) Created: 2017-04-25 Updated: 2019-07-10 Resolved: 2019-07-10 |
|
| Status: | Closed |
| Project: | MariaDB ColumnStore |
| Component/s: | MariaDB Server |
| Affects Version/s: | 1.0.6, 1.0.7, 1.0.8 |
| Fix Version/s: | Icebox |
| Type: | Bug | Priority: | Major |
| Reporter: | Adam | Assignee: | Andrew Hutchings (Inactive) |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | innodb, optimizer | ||
| Environment: |
Linux 2.6.32-573.7.1.el6.x86_64 #1 SMP Tue Sep 22 22:00:00 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux |
||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Epic Link: | ColumnStore Compatibility Improvements | ||||||||
| Sprint: | 2017-9 | ||||||||
| Description |
|
I'm running into an issue on 1.0.6, 1.0.7, and 1.0.8 when performing a cross engine select against a view containing a group by atop innodb tables. If I use a straight_join optimizer hint I can force the optimizer to not perform an aria temp table on disk; I get the correct result set (albeit with a query execution time of 4 sec). It is only when the optimizer decides to use a temp table on disk (aria) that the performance degrades considerably (27 sec, 10 for the temp table and 17 for sending data) and the group by result set only returns a value for the view's first pivot GROUP_CONCAT(IF()); the remaining pivot columns contain an empty string ('', not null). The same view atop innodb tables within maraidb 10.1.19, with the same explain plan using a temp table on disk returns the correct result set in under 600 ms. As I am able to get the cross engine select to run with a group by and return the correct result set; I'd be more inclined that the underlying problem is with the use of aria temp tables and the columnstore optimizer. Reference https://jira.mariadb.org/projects/MCOL/issues/MCOL-515?filter=allopenissues |
| Comments |
| Comment by Adam [ 2017-04-25 ] |
|
Test case attached. If one moves the group by out of the view the optimizer generates a more optimal and consistent explain plan returning the correct reult set within 110 ms. THis is the desired behavior and is consistent with MariaDB 10.2 releases. |
| Comment by Andrew Hutchings (Inactive) [ 2019-07-10 ] |
|
Should be gone in 1.4 if it isn't already fixed. |