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 | 
                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:
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 + 
                            cannot be pushed down, and that (for example) a join
                            on an constantINT column and a
                            BIGINT column also
                            cannot be pushed down.
                        
                            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.
                        
                            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.
                        
                            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 copymysql> 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)
                    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:
                            The status variables
                            Ndb_pushed_queries_defined,
                            Ndb_pushed_queries_dropped,
                            Ndb_pushed_queries_executed,
                            and
                            Ndb_pushed_reads.
                        
                            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.