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/85bbea8dbb9c01defa993e44a5b16c43ef851fbd

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