Hi Holyfoot,
Your fix creates more lists, all of them containing one element, but it
does only one reorganization. My fix does a reorganization whenever a 33rd
element is processed but creates less lists. I agree that reducing the
number of reorganizations to one is a better way to fix the problem. So I
will use your fix.
Thanks,
Jacob
Jacob B. Mathew
Spider and Server Developer
MariaDB Corporation
+1 408 655 8999 (mobile)
jacob.b.mathew (Skype)
jacob.mathew@MariaDB.com
On Sun, May 13, 2018 at 2:36 PM, Alexey Botchkov
Hi, Jacob.
Your fix: https://github.com/MariaDB/server/commit/85bbea8dbb9c01defa993e44a5b16c 43ef851fbd
I don't like the way your fix work. So after we get the 32-th item we do the reorganize_into_single_ field_col_val() trick that turns one element with 32 values into 32 elements with a single value. Then as we get 33-th element, we again put it into that first element, and do so for the next 31 element then call the reorganize_ again.
I think we should just keep the 'one-value' list after the 'reorganize_' So my fix would be like this: --- a/sql/partition_info.cc +++ b/sql/partition_info.cc @@ -1996,9 +1996,11 @@ part_column_list_val *partition_info::add_column_value(THD *thd) into the structure used for 1 column. After this we call ourselves recursively which should always succeed. */ + num_columns= curr_list_object; if (!reorganize_into_single_field_col_val(thd)) { - DBUG_RETURN(add_column_value(thd)); + if (!init_column_part(thd)) + DBUG_RETURN(add_column_value(thd)); }
Best regards. HF