Hi, Alexey!

Actually the bug is applicable only to primary key and only when
default field list is set (i.e. empty KEY() clause). So updated the
patch accordingly. Please peek again.

On Wed, May 13, 2020 at 2:40 PM Alexey Botchkov <holyfoot@mariadb.com> wrote:
>
> Hello, Aleksey!
>
> > commit 5ef168e00f7b8c821463e46535a4beccb47ec8ea
> +          if (key_info->flags & HA_INVISIBLE_KEY)
> +            continue;
>
> I'd add || !(key_info->flags & HA_NOSAME).
> Can the non-unique index participate in the KEY partitioning?
>
> +          for (uint kp= 0; kp < key_info->user_defined_key_parts; ++kp)
> +          {
> +            const KEY_PART_INFO &key_part= key_info->key_part[kp];
> +            for (Field **part_field= tab_part_info->part_field_array;
> +                *part_field; ++part_field)
> +            {
> +              if (*part_field == key_part.field)
> +              {
> +                *partition_changed= TRUE;
> +                goto search_finished;
> +              }
> +            } // for (part_field)
> +          } // for (key_part)
>
> So you check if the key has any of the partitioning fields in it.
> In this case we are going to disallow INPLACE with no reason if the
> unrelated key is removed just containing the primary key column.
> I'd say we should check for the exact match, when the key has
> all the part_field_array in that exact order. Disagree?
>
> And for the test - please add the case for a table with no PRIMARY KEY, bug with the UNIQUE instead.
>
> Best regards!
> HF
>


-- 
All the best,

Aleksey Midenkov
@midenok