[MDEV-23825] Join select_handler and Pushdown_select + XPand changes Created: 2020-09-26  Updated: 2020-10-06  Resolved: 2020-09-27

Status: Closed
Project: MariaDB Server
Component/s: Optimizer
Fix Version/s: 10.5.7

Type: Task Priority: Major
Reporter: Alexander Barkov Assignee: Alexander Barkov
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Blocks
blocks MDEV-23803 Fix pushdown select not to use TABLE ... Open
Relates

 Description   

Under terms of this task we'll do two things:

  • Join classes select_handler and Pushdown_select into a single class
    The current implementation with two parallel classes (select_handler and Pushdown_select) is hard to follow. Non of them can work without the other. The two-step construction stage looks too complex:

      select_lex->select_h= select_lex->find_select_handler(thd);
      if (select_lex->select_h)
      {
        /* Create a Pushdown_select object for later execution of the query */
        if (!(select_lex->pushdown_select=
          new (thd->mem_root) Pushdown_select(select_lex,
                                              select_lex->select_h)))
        {
          delete select_lex->select_h;
          select_lex->select_h= NULL;
          DBUG_RETURN(TRUE);
        }
      }
    

    With a single object it will be as simple as:

      select_lex->pushdown_select= select_lex->find_select_handler(thd);
    

    The destruction stage looks dangerous in the current implementation:

    Pushdown_select::~Pushdown_select()
    {
     if (handler->table)
       free_tmp_table(handler->thd, handler->table);
     delete handler;
     select->select_h= NULL;
    }
    

    So the server deletes a Pushdown_select instance, which then deletes the select_handler. It's much safer just to delete a single object.

  • Make it possible for the engine (e.g. XPand) to create a TABLE on its own and then reuse it during select_handler() creation time by assigning to select_handler::table. This is needed to avoid two executions of create_tmp_table() which currenly happen with XPand. So during the preparation stage, the TABLE will already be assigned to select_handler::table and select_handler will not need to make it again during the preparation stage. The method will looks about like this:

    bool select_handler::prepare()
    {
      /*
        Some engines (e.g. XPand) initialize "table" on their own.
        So we need to create a temporary table only if "table" is NULL.
      */
      if (!table && !(table= create_tmp_table(thd, select)))
        DBUG_RETURN(true);
      DBUG_RETURN(table->fill_item_list(&result_columns));
    }
    

    Notice, in the new reduction, the table is created only if select_handler::table is NULL.


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