|Re: Anti-comrpession||Tim Callaghan||5/2/13 7:10 AM|
I've never seen this before, can you please give us a little more information:
1. Attach your my.cnf file
2. Include the output of "show variables like 'tokudb%';"
I'm curious to see what your default compression is set to.
On Thursday, May 2, 2013 1:06:01 AM UTC-4, Shlomi Noach wrote:
I'm evaluating 5.5.30-tokudb-7.0.1-MariaDB-log after having compiled it from source.
|Re: Anti-comrpession||Tim Callaghan||5/2/13 8:17 AM|
On further investigation we now see what the issue is. You are converting a compressed InnoDB table, with key_block_size=4. In creating the TokuDB version of this table our code is picking up that 4K and using it as the node size for the TokuDB table. TokuDB node size defaults to 4M (much larger than 4K), and can be overriden by setting tokudb_block_size.
I've added a bug ticket to get this fixed. For now to see the benefit of TokuDB compression you'll need to either alter an uncompressed InnoDB table or load directly into the TokuDB table the way you loaded the InnoDB table.
Please let us know your findings.
|Re: Anti-comrpession||Tim Callaghan||5/2/13 10:24 AM|
I'm not sure what will happen, can you try it and let me know?
The solution is that we'll be modifying our alter table code to strip out this option, I'm not sure there are any other work-arounds at the moment.
On Thursday, May 2, 2013 1:12:13 PM UTC-4, Shlomi Noach wrote:
|Re: Anti-comrpession||Shlomi Noach||5/2/13 10:49 AM|
Will try next.
|Re: Anti-comrpession||Shlomi Noach||5/3/13 4:37 AM|
The trick with
ALTER TABLE ENGINE=TokuDB KEY_BLOCK_SIZE=4096
did not do what I was hoping for: still got very long ALTER time and a larger TokuDB table than original InnoDB.
So either dumping everything out, or creating a new table of TokuDB engine, copying everything there, swapping the new table instead of the old InnoDB one and dropping the old one. I'm trying just that now. Another advantage of this is that the files on disk are named after the table and not after MySQL's own temporary naming.
|Re: Anti-comrpession||Tim Callaghan||5/3/13 4:53 AM|
Thanks for trying, as we fix this issue we'll be looking for any other non-TokuDB attributes that we need to eliminate as part of the alter table operation.
|Re: Anti-comrpession||Mark Callaghan||6/4/13 7:36 AM|
Does this help?
On Tue, Jun 4, 2013 at 7:27 AM, Nail Kashapov <nail.k...@gmail.com> wrote:
|Re: Anti-comrpession||Shlomi Noach||6/4/13 10:01 PM|
Did you happen to try it with a single command?
alter table table_namedrop primary key, add primary key (obj_id), key_block_size=0 ;
|Re: Anti-comrpession||Shlomi Noach||6/4/13 10:05 PM|
The bug helps in knowing other share the same trouble; but going to ROW_FORMAT=DEFAULT does not really help since we really want something like ROW_FORMAT=TOKUDB_LZMA, and the problem arises with the KEY_BLOCK_SIZE. I will try suggested KEY_BLOCK_SIZE=0 and report.
|Re: Anti-comrpession||Shlomi Noach||6/5/13 12:12 AM|
doing it all in one command works just well. So, DROP all KEYs, recreate them, ENGINE=TokuDB, KEY_BLOCK_SIZE=0, all in one ALTER.
See some experiments here:
|Re: Anti-comrpession||Shlomi Noach||7/28/13 2:07 AM|
Checking on the latest 7.0.3 release I don't see this as fixed. Nor can I find the bug reported in GitHub's Issues. Can you please update on this?
|Re: Anti-comrpession||Rich Prohaska||7/29/13 12:12 PM|
Github issues #58 and #62 now refer to this bug.