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 <holyfoot@mariadb.com> wrote:

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