[MCOL-1031] create non columnstore table from columnstore select with joins is slow Created: 2017-11-14 Updated: 2019-07-10 Resolved: 2019-07-10 |
|
| Status: | Closed |
| Project: | MariaDB ColumnStore |
| Component/s: | MariaDB Server |
| Affects Version/s: | 1.1.1 |
| Fix Version/s: | Icebox |
| Type: | Bug | Priority: | Major |
| Reporter: | David Thompson (Inactive) | Assignee: | Unassigned |
| Resolution: | Won't Fix | Votes: | 2 |
| Labels: | None | ||
| Description |
|
Generate a large date file and load this to a table loans_table:
The following create table will be very slow (hours):
Change this to insert select and it will be fast:
I believe what is happening is that the create table is getting executed as effectively vtable mode 0 so the joins are done as nested loop joins assuming indexes which is very slow. The insert into select is correctly pushed down to columnstore and so executes at a more appropriate speed. |
| Comments |
| Comment by Thorsten [ 2018-02-01 ] |
|
Hi, Normaly "create tabla xy as select ..." are very fast but not now. If I make: create table tmp as select * from (select pzn_id,sum(VAL_36_200) Packungen_MariaDB from nvi_kt_de_13680_201712.fact_nvi_kt_de_13680 f group by f.pzn_id) t where Packungen_MariaDB>0 ; if I create the table and use insert CREATE TABLE `tmp` (`pzn_id` INT(10) UNSIGNED NULL DEFAULT NULL, `Packungen_MariaDB` DECIMAL(32,0) NULL DEFAULT NULL ) COLLATE='utf8_general_ci' ENGINE=InnoDB; the statement ist ready after 2 seconds. I don´t understand this behavior. And the second thing is: BEGIN NOT ATOMIC set @tmp_sql ="DROP TABLE IF EXISTS tmp "; set @tmp_sql ="CREATE TABLE `tmp` (`pzn_id` INT(10) UNSIGNED NULL DEFAULT NULL, `Packungen_MariaDB` DECIMAL(32,0) NULL DEFAULT NULL ) COLLATE='utf8_general_ci' ENGINE=InnoDB"; set @tmp_sql ="insert into tmp select pzn_id,sum(VAL_36_200) Packungen_MariaDB from fact_nvi_kt_de_13680 f group by f.pzn_id having sum(VAL_36_200)>0"; END $ Can anyone explain it? Thanks for help. Thorsten |
| Comment by Andrew Hutchings (Inactive) [ 2019-07-10 ] |
|
Should go away in 1.4 |