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 constant
INT
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.