[MCOL-4410] SELECT bypasses select handler if @variables are involved in the query projection list Created: 2020-11-24 Updated: 2022-05-16 Resolved: 2021-05-06 |
|
| Status: | Closed |
| Project: | MariaDB ColumnStore |
| Component/s: | None |
| Affects Version/s: | 1.4.4 |
| Fix Version/s: | 5.6.1 |
| Type: | Bug | Priority: | Blocker |
| Reporter: | Todd Coker (Inactive) | Assignee: | Daniel Lee (Inactive) |
| Resolution: | Fixed | Votes: | 1 |
| Labels: | None | ||
| Environment: |
SkySQL CentOS 7.8 |
||
| Sprint: | 2021-7 |
| Description |
|
|
| Comments |
| Comment by Roman [ 2021-01-11 ] | ||||||||||||||||||||||||||||||||||||||||
|
I disagree the issue is connected with the MDEV-24298 | ||||||||||||||||||||||||||||||||||||||||
| Comment by Gregory Dorman (Inactive) [ 2021-02-21 ] | ||||||||||||||||||||||||||||||||||||||||
|
drrtuy is right. This is connected to nothing. Here is a simpler reproduction (10.5.8 / 5.5.1). Session variables passed as parameters to functions throw MDB optimizer off, and he is not pushing queries down to select handler. This has to be fixed somewhere in the server. Probably needs to become an MDEV ticket too. Note - I have recollection that this is NOT happening with XPAND. MariaDB [mcol4110]> create table t1 (a int) engine=columnstore; MariaDB [mcol4110]> MariaDB [mcol4110]> explain select trim('a') from t1;
-----
----- MariaDB [mcol4110]> explain select trim(@d) from t1;
-----
----- The offending line in the original claim is DATEDIFF(@asOfDate,th.effective_due_date) AS days_late, | ||||||||||||||||||||||||||||||||||||||||
| Comment by Gagan Goel (Inactive) [ 2021-05-04 ] | ||||||||||||||||||||||||||||||||||||||||
|
For QA: To reproduce the issue, DDLs are in the comment above from Todd Coker, and the SELECT query is in the issue description. | ||||||||||||||||||||||||||||||||||||||||
| Comment by Daniel Lee (Inactive) [ 2021-05-06 ] | ||||||||||||||||||||||||||||||||||||||||
|
Build tested: 5.6.1-1 ( Drone #2326) This is the explain output that we are expecting? -----
-----
----- | ||||||||||||||||||||||||||||||||||||||||
| Comment by Gregory Dorman (Inactive) [ 2021-05-06 ] | ||||||||||||||||||||||||||||||||||||||||
|
Yes. PUSHED SELECT means exactly what it says - the entire statement was delivered to CS. Prior to the fix you had a dozen operations tables accessed separately by the server, and joins performed by the server as well, resulting in a huge slowdown, and even crashes. | ||||||||||||||||||||||||||||||||||||||||
| Comment by Daniel Lee (Inactive) [ 2021-05-06 ] | ||||||||||||||||||||||||||||||||||||||||
|
Closed per test result in my last comment |