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

LP:834739 - Wrong result with 3-way inner join, LooseScan,multipart keys

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:

      Description

      The following query:

      SELECT * FROM t3
      WHERE t3.a IN (
      SELECT t5.a FROM t2, t4, t5 WHERE ( t2.c = t5.a ) AND ( t2.b = t5.b )
      );

      returns 45 rows when executed with LooseScan, even though t3 contains just 15 rows. In addition, the query plan always contains FirstMatch regardless of whether the firstmatch switch is on or off.

      Explain:

      -------------------------------------------------------------------------------------------------------------+

      id select_type table type possible_keys key key_len ref rows Extra

      -------------------------------------------------------------------------------------------------------------+

      1 PRIMARY t5 index a a 10 NULL 2 Using where; Using index; LooseScan
      1 PRIMARY t4 ALL NULL NULL NULL NULL 3 Using join buffer (flat, BNL join)
      1 PRIMARY t2 ref b b 5 test.t5.b 2 Using where; FirstMatch(t5)
      1 PRIMARY t3 ALL NULL NULL NULL NULL 15 Using where; Using join buffer (flat, BNL join)

      -------------------------------------------------------------------------------------------------------------+

      minimal optimizer switch: semijoin=on,loosescan=on

      full optimizer switch:

      index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,index_condition_pushdown=off,derived_merge=off,derived_with_keys=off,firstmatch=off,loosescan=on,materialization=off,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=off,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=off,semijoin_with_cache=off,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on

      bzr version-info:

      revision-id: <email address hidden>
      date: 2011-08-23 15:51:47 +0300
      build-date: 2011-08-26 16:50:13 +0300
      revno: 3166
      branch-nick: maria-5.3

      test case:

      DROP TABLE IF EXISTS t2;
      CREATE TABLE t2 ( b int, c int, KEY (b)) ;
      INSERT INTO t2 VALUES (1,0),(1,0),(9,0),(1,0),(5,0);

      DROP TABLE IF EXISTS t3;
      CREATE TABLE t3 ( a int);
      INSERT INTO t3 VALUES (0),(0),(0),(0),(0),(0),(0),(0),(0),(0),(0),(0),(0),(0),(0);

      DROP TABLE IF EXISTS t4;
      CREATE TABLE t4 ( a int);
      INSERT INTO t4 VALUES (0),(0),(0);

      DROP TABLE IF EXISTS t5;
      CREATE TABLE t5 ( b int, a int , KEY (a,b)) ;
      INSERT INTO t5 VALUES (7,0),(9,0);

      SELECT * FROM t3
      WHERE t3.a IN (
      SELECT t5.a FROM t2, t4, t5 WHERE ( t2.c = t5.a ) AND ( t2.b = t5.b )
      );

        Gliffy Diagrams

          Attachments

            Activity

            Hide
            psergey Sergei Petrunia added a comment -

            Re: Wrong result with 3-way inner join, LooseScan,multipart keys
            > In addition, the query plan always contains FirstMatch regardless of whether the firstmatch switch is on or off.

            This is expected, When LooseScan strategy is taking care of removing duplicates produced by a multi-table subquery, one can see EXPLAIN outputs like this:

            table_x LooseScan
            ...
            table_y FirstMatch(table_x)

            Show
            psergey Sergei Petrunia added a comment - Re: Wrong result with 3-way inner join, LooseScan,multipart keys > In addition, the query plan always contains FirstMatch regardless of whether the firstmatch switch is on or off. This is expected, When LooseScan strategy is taking care of removing duplicates produced by a multi-table subquery, one can see EXPLAIN outputs like this: table_x LooseScan ... table_y FirstMatch(table_x)
            Hide
            psergey Sergei Petrunia added a comment -

            Re: Wrong result with 3-way inner join, LooseScan,multipart keys
            Note that the result is correct if I do "SET join_cache_level=0".

            EXPLAIN shows that table t4 is "with LooseScan's range", and it uses join buffering.

            Show
            psergey Sergei Petrunia added a comment - Re: Wrong result with 3-way inner join, LooseScan,multipart keys Note that the result is correct if I do "SET join_cache_level=0". EXPLAIN shows that table t4 is "with LooseScan's range", and it uses join buffering.
            Hide
            ratzpo Rasmus Johansson added a comment -

            Launchpad bug id: 834739

            Show
            ratzpo Rasmus Johansson added a comment - Launchpad bug id: 834739

              People

              • Assignee:
                psergey Sergei Petrunia
                Reporter:
                philipstoev Philip Stoev
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: