Sergei Petrunia 80ff192cb3 MDEV-39005: Assertion failure on hint-forced Split-Materialized plan ...

The problem: consider a query in form:
  t1 JOIN (SELECT a FROM t2 GROUP BY a) dt ON dt.a=t1.a

After fix for MDEV-30877, the optimizer computes the number of GROUP BY
groups that we will have in the materialized derived table. It is saved
into TABLE(dt)->used_stat_records and propagates into
TABLE(dt)->opt_range_condition_rows.

On the other hand, the Split-Materialized optimization tries to compute
the number of rows it expects to find in the Split-Materialized derived
table.

These two numbers may come into disagreement: Split-Materialized may
produce a higher number, save it into JOIN_TAB::records and cause this
assertion in apply_selectivity_for_table() to fail:

    double table_records= rows2double(s->records);
    DBUG_ASSERT(table_records == 0 ||
                sel <= s->table->opt_range_condition_rows /
                table_records);

We will have sel=1.0 but opt_range_condition_rows < table_records.

Cardinality computations in Split-Materialized code omit a lot, for example
they omit the fact GROUP BY operation will reduce the number or rows.

For now, use a trivial fix: make sure Split-Materialized's estimate of
JOIN_TAB::records doesn't exceed the derived table size.

2026-07-03 15:08:53 +03:00

55 KiB

Raw Permalink Blame History

View Raw