- `ndb_join_pushdown`

  Table 21.249 Type and value information for ndb_join_pushdown

  Property | Value
  --- | ---
  Name | `ndb_join_pushdown`
  Command Line | No
  System Variable | Yes
  Status Variable | No
  Option File | No
  Scope | Both
  Dynamic | Yes
  Type |
  Default, Range | TRUE (Version: 5.1.51-ndb-7.2.0)
  Notes | DESCRIPTION: Enables pushing down of joins to data nodes

  Property | Value
  --- | ---

  This variable controls whether joins on `NDB` tables are pushed down to the NDB kernel (data nodes). Previously, a join was handled using multiple accesses of `NDB` by the SQL node; however, when `ndb_join_pushdown` is enabled, a pushable join is sent in its entirety to the data nodes, where it can be distributed among the data nodes and executed in parallel on multiple copies of the data, with a single, merged result being returned to mysqld. This can reduce greatly the number of round trips between an SQL node and the data nodes required to handle such a join.

  By default, `ndb_join_pushdown` is enabled.

  Conditions for NDB pushdown joins. In order for a join to be pushable, it must meet the following conditions:

  1. Only columns can be compared, and all columns to be joined must use exactly the same data type.

     This means that expressions such as `t1.a = t2.a + `constant`` cannot be pushed down, and that (for example) a join on an `INT` column and a `BIGINT` column also cannot be pushed down.

  2. Queries referencing `BLOB` or `TEXT` columns are not supported.

  3. Explicit locking is not supported; however, the `NDB` storage engine's characteristic implicit row-based locking is enforced.

     This means that a join using `FOR UPDATE` cannot be pushed down.

  4. In order for a join to be pushed down, child tables in the join must be accessed using one of the `ref`, `eq_ref`, or `const` access methods, or some combination of these methods.

     Outer joined child tables can only be pushed using `eq_ref`.

     If the root of the pushed join is an `eq_ref` or `const`, only child tables joined by `eq_ref` can be appended. (A table joined by `ref` is likely to become the root of another pushed join.)

     If the query optimizer decides on `Using join cache` for a candidate child table, that table cannot be pushed as a child. However, it may be the root of another set of pushed tables.

  5. Joins referencing tables explicitly partitioned by `[LINEAR] HASH`, `LIST`, or `RANGE` currently cannot be pushed down.

  You can see whether a given join can be pushed down by checking it with `EXPLAIN`; when the join can be pushed down, you can see references to the `pushed join` in the `Extra` column of the output, as shown in this example:

      Press CTRL+C to copy mysql> EXPLAIN
                ->     SELECT e.first_name, e.last_name, t.title, d.dept_name
                ->         FROM employees e
                ->         JOIN dept_emp de ON e.emp_no=de.emp_no
                ->         JOIN departments d ON d.dept_no=de.dept_no
                ->         JOIN titles t ON e.emp_no=t.emp_no\G
            *************************** 1. row ***************************
                       id: 1
              select_type: SIMPLE
                    table: d
                     type: ALL
            possible_keys: PRIMARY
                      key: NULL
                  key_len: NULL
                      ref: NULL
                     rows: 9
                    Extra: Parent of 4 pushed join@1
            *************************** 2. row ***************************
                       id: 1
              select_type: SIMPLE
                    table: de
                     type: ref
            possible_keys: PRIMARY,emp_no,dept_no
                      key: dept_no
                  key_len: 4
                      ref: employees.d.dept_no
                     rows: 5305
                    Extra: Child of 'd' in pushed join@1
            *************************** 3. row ***************************
                       id: 1
              select_type: SIMPLE
                    table: e
                     type: eq_ref
            possible_keys: PRIMARY
                      key: PRIMARY
                  key_len: 4
                      ref: employees.de.emp_no
                     rows: 1
                    Extra: Child of 'de' in pushed join@1
            *************************** 4. row ***************************
                       id: 1
              select_type: SIMPLE
                    table: t
                     type: ref
            possible_keys: PRIMARY,emp_no
                      key: emp_no
                  key_len: 4
                      ref: employees.de.emp_no
                     rows: 19
                    Extra: Child of 'e' in pushed join@1
            4 rows in set (0.00 sec)

  Note

  If inner joined child tables are joined by `ref`, and the result is ordered or grouped by a sorted index, this index cannot provide sorted rows, which forces writing to a sorted tempfile.

  Two additional sources of information about pushed join performance are available:

  1. The status variables `Ndb_pushed_queries_defined`, `Ndb_pushed_queries_dropped`, `Ndb_pushed_queries_executed`, and `Ndb_pushed_reads`.

  2. The counters in the `ndbinfo.counters` table that belong to the `DBSPJ` kernel block. See Section 21.5.10.10, “The ndbinfo counters Table”, for information about these counters. See also The DBSPJ Block, in the NDB Cluster API Developer Guide.