[MDEV-4405] Dynamic Columns compression Created: 2013-04-19 Updated: 2015-11-17 |
|
| Status: | Open |
| Project: | MariaDB Server |
| Component/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Minor |
| Reporter: | VAROQUI Stephane | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||
| Description |
|
We are facing a show stopper for fast insert and restitution using Dynamic Columns compression. Objective is to provide a view of the original table hiding dynamic column compression not to be forced to change all the software relying on original table design We have 2 paths
With compress uncompress functions, creating the view failed on Using InnoDB compression we can now create a view but facing heavy negative scalability when running concurrent LOAD DATA INFILE Fixing one or the other issue would put MariaDB as the solution of choice proposed from this editor to clients regarding big data sizing |
| Comments |
| Comment by Patryk Pomykalski [ 2013-04-19 ] |
|
How would the view look like? |
| Comment by VAROQUI Stephane [ 2013-04-19 ] |
|
set optimizer_switch='derived_merge=off'; drop table if exists t1; insert into t1 select 2 ,b, 1 from t1 where a=1; insert into t1 select 12 ,b, 1 from t1 where a=1; – creating a table to store column b that will be our indice to dynamic column drop table if exists i1; set global max_allowed_packet=1024*1024*100; – injecting t1 to compressed dynamic column delimiter // CREATE PROCEDURE spa() – recreate t1 from compressed t2 CREATE VIEW `v2` AS – creating uncompressed table t3 from t2 – recreate t1 from uncompressed t3 – create t4 innodb compression from uncompressed table drop table if exists t4; – recreate t1 from compressed t4 Stephane Varoqui | Senior Consultant EMEA |
| Comment by Patryk Pomykalski [ 2013-04-20 ] |
|
It works if you substitute "( SELECT a , UNCOMPRESS(dc) dc FROM t2 )" as another view. |
| Comment by VAROQUI Stephane [ 2013-04-21 ] |
|
Hi Patryk, Well in our first test it looks like the conditions have not been push down for internal view or that derived_merge is lost lost . The idea is not to decompress for every record of i1 I'll ask our client to review again if we have missed something here like an index that would have cause us to miss interpreted that result Thanks for the investigation so far . Sandrine, Simon, can provide us an explain of the embedded view test case . Can you also retest on mariadb 10 as it looks like innodb compression is much much better in that release . Stéphane Stephane Varoqui | Senior Consultant EMEA |