Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-16829

Odd code in Item_subselect::is_expensive

    XMLWordPrintable

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Incomplete
    • 10.0
    • N/A
    • Optimizer
    • None

    Description

      Item_subselect::is_expensive() has this code:

        for (SELECT_LEX *sl= unit->first_select(); sl; sl= sl->next_select())
        {
          JOIN *cur_join= sl->join;
          if (!cur_join)
            continue;
       
          /*
            Subqueries whose result is known after optimization are not expensive.
            Such subqueries have all tables optimized away, thus have no join plan.
          */
          if (cur_join->optimized &&
              (cur_join->zero_result_cause || !cur_join->tables_list))
            return false;
      

      The loop walks through parts of UNION. If we find a SELECT that has non-NULL
      join->zero_result_cause, we have is_expensive()=FALSE.
      What about cases like

       (SELECT FROM t1 WHERE 1=2 
        UNION
        SELECT sum(col) FROM very_big_table
       )
      

      Item_subselect::is_expensive() will return FALSE for it, which is wrong.

      Attachments

        Issue Links

          Activity

            People

              psergei Sergei Petrunia
              psergei Sergei Petrunia
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.