[MDEV-22415] Single table UPDATE/DELETE doesn't use non-semijoin Materialization Created: 2020-04-29  Updated: 2024-01-30

Status: Open
Project: MariaDB Server
Component/s: Optimizer
Fix Version/s: 11.6

Type: New Feature Priority: Major
Reporter: Sergei Petrunia Assignee: Igor Babaev
Resolution: Unresolved Votes: 1
Labels: optimizer-feature, subquery

Issue Links:
Blocks
is blocked by MDEV-18511 CTE support for UPDATE and DELETE sta... Stalled
Relates
relates to MDEV-7487 Semi-join optimization for single-tab... Closed
relates to MDEV-22248 Optimizer chooses wrong strategy on d... Open
relates to MDEV-22377 Subquery in an UPDATE query uses full... Closed

 Description   

Stumbled on this in MDEV-22377.

Single-table UPDATE/DELETEs do not support Materialization (I mean non-semi-join one, for the issue with semi-joins, see MDEV-7487).

The reason is in JOIN::choose_subquery_plan():

  #0  JOIN::choose_subquery_plan (this=0x7ffc40017368, join_tables=3) at /home/psergey/dev-git/10.4-rel/sql/opt_subselect.cc:6467
  #1  0x0000555555db8ad8 in make_join_statistics (join=0x7ffc40017368, tables_list=..., keyuse_array=0x7ffc40017658) at /home/psergey/dev-git/10.4-rel/sql/sql\_select.cc:5590
  #2  0x0000555555dac671 in JOIN::optimize_inner (this=0x7ffc40017368) at /home/psergey/dev-git/10.4-rel/sql/sql_select.cc:2254
  #3  0x0000555555da9fb6 in JOIN::optimize (this=0x7ffc40017368) at /home/psergey/dev-git/10.4-rel/sql/sql\_select.cc:1601
  #4  0x0000555555d301ab in st_select_lex::optimize_unflattened_subqueries (this=0x7ffc40005470, const_only=false) at /home/psergey/dev-git/10.4-rel/sql/sql_lex.cc:4188
  #5  0x0000555555e701d2 in mysql_update (thd=0x7ffc40000d50, table_list=0x7ffc40012450, fields=..., values=..., conds=0x7ffc40016e80, order_num=0, order=0x0, limit=18446744073709551615, ignore=false, found_return=0x7fffdcbb0e70, updated_return=0x7fffdcbb0f30) at /home/psergey/dev-git/10.4-rel/sql/sql_update.cc:516

    {
      /*
        TODO: outer_join can be NULL for DELETE statements.
        How to compute its cost?
      */
      outer_lookup_keys= 1;
    }

Here, we don't know how many times the subquery will be evaluated (if we assume it's evaluated once, Materialization doesn't make sense).

Can we figure out how many rows single-table UPDATE/DELETE is going to examine?
Not yet: mysql_update() calls optimize_unflattened_subqueries:

  if (select_lex->optimize_unflattened_subqueries(false))
    DBUG_RETURN(TRUE);

before it does partition pruning or range analysis.



 Comments   
Comment by Sergei Petrunia [ 2020-09-09 ]

According to igor, this task should be solved by the patch for MDEV-18511.

Generated at Thu Feb 08 09:14:34 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.