maria-developers team mailing list archive

[Jacob Mathew <jacob.mathew@xxxxxxxxxxx>]

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@xxxxxxxxxxx


On Sun, May 13, 2018 at 2:36 PM, Alexey Botchkov <holyfoot@xxxxxxxxxxx>
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
>
>