Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Not a Bug
-
10.3(EOL), 10.4(EOL)
-
None
Description
Consider this testcase:
create table ten(a int primary key); |
insert into ten values (0),(1),(2),(3),(4),(5),(6),(7),(8),(9); |
|
|
create table one_k(a int primary key); |
insert into one_k select A.a + B.a* 10 + C.a * 100 from ten A, ten B, ten C; |
|
|
create table t21 ( |
a varchar(500) COLLATE utf8mb4_bin |
);
|
insert into t21 select A.a+1000*B.a from one_k A, one_k B; |
|
|
set max_heap_table_size=32000; # just some low value to overflow the heap table. |
Put a breakpoint in create_internal_tmp_table_from_heap, then run
select conc_val, count(*) from t21 group by conc_val ; |
when the Aria table is created, one can see:
(gdb) p maria_max_key_length()
|
$53 = 1000
|
(gdb) p this
|
$55 = (ha_maria * const) 0x7fff6c165f38
|
(gdb) p table->key_info[0]
|
$57 = {key_length = 2000, flags = 2083, user_defined_key_parts = 1, ...
|
So, key_length larger than maria_max_key_length().
I didn't see this produce any problem, except that it might be confusing for
the users. How come GROUP BY code can use a unique key of this length, while
SJ-Materialization is not applicable for such long keys?
Attachments
Issue Links
- relates to
-
MDEV-20279 Increase Aria index length limit
-
- Closed
-
Activity
SJ-Materialization, as an internal optimization, perhaps could be able to use that too
This is because if a key for an internal temporary is longer than maria_max_key_length, it changes the key to an internal unique key, which can have any size. This is why we can DISTINCT and GROUP BY over anything without any size limitations.