maria-developers team mailing list archive

[Sergei Golubchik <serg@xxxxxxxxxxx>]

Hi, Sachin!

On Mar 20, Sachin Setiya wrote:
> revision-id: f6166101e0f (mariadb-10.4.3-86-gf6166101e0f)
> parent(s): 8076c594ce2
> author: sachinsetia1001@xxxxxxxxx <sachin.setiya@xxxxxxxxxxx>
> committer: Sachin <sachin.setiya@xxxxxxxxxxx>
> timestamp: 2019-03-19 16:43:43 +0530
> message:
> 
> MDEV-18904 Assertion `m_part_spec.start_part >= m_part_spec.end_part' failed in ha_partition::index_read_idx_map
> 
> We do not support long unique index in partition.

Why not?

I would think that the assert is wrong, there is no reason why
ha_partition::index_read_idx_map() would always hit just one partition.

ha_partition::index_read_map() doesn't have this assert. And if you
check the history of the assert you'll find that the comment originally
was /* How can it be more than one partition with the current use? */

So, apparently now you've introduced a new "use" and there can be more
than one partition, and removing the assert looks justified.

> +CREATE TABLE t1 (a int , unique(a) using hash) PARTITION BY HASH (a) PARTITIONS 2;
> +ERROR HY000: Long unique index is not supported in partition

Also - for the future - there are no "long unique" indexes from the user
point of view. This is only an internal name. The SQL syntax does use
"long unique" concept, documentation doesn't, error messages don't. That
is, users simply won't understand what you mean here.

If we'll need an error here, I'd suggest, for example,

  HASH UNIQUE indexes cannot be used in partitioned tables.

but it's not strictly correct, if some engine would implement hash
indexes natively. The more precise message could be

  HASH UNIQUE indexes cannot be used in par    titioned MyISAM tables.

or

  Partitioned MyISAM tables do not support HASH UNIQUE indexes.

(where "MyISAM" is a parameter, of course).

But, again, I am not yet convinced that we need this limitation at all.

Regards,
Sergei
Chief Architect MariaDB
and security@xxxxxxxxxxx