Hello, Vicențiu. In the SELECT you mentioned SELECT 1 FROM t1 NATURAL LEFT JOIN t1 AS t2 the SPATIAL key should not be used, just doesn't fit. And I must note that i couldn't reproduce the testcase as it was described. What i got was: +------+-------------+-------+------+---------------+------+---------+------+------+------------------------------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +------+-------------+-------+------+---------------+------+---------+------+------+------------------------------------------------+ | 1 | SIMPLE | t1 | ALL | NULL | NULL | NULL | NULL | 2 | | | 1 | SIMPLE | t2 | ALL | a | NULL | NULL | NULL | 2 | Range checked for each record (index map: 0x1) | +------+-------------+-------+------+---------------+------+---------+------+------+------------------------------------------------+ The TABLE:create_key_part_by_field wasn't called during the process. What function actually returns the key_length of 0? The Field_geom::pack_length() returns not-zero for me. Best regards. HF 09.03.2015 16:44, Vicențiu Ciorbaru wrote:

Hi Holyfoot!

I've made some changes regarding key_length computation to fix MDEV-6838. Changing this seems to have lead to us discovering another issue outlined in MDEV-7682 (that I've just created).

It seems that the spatial key returns a key_length of 0. I've spoken to Sergei Petrunia and we are not sure about this particular case. pack_length returns a bigger number (12). According to the other comments in the code, pack_length also returns the length field associated with the column, but we are only interested in the length of the column field, without any metadata information. The function TABLE:create_key_part_by_field adds the metadata length itself afterwards.

Do you have any input on this issue, namely why the key_length is returned as 0 for the LINESTRING column?

Regards, Vicentiu