<<toc>>
Index Condition Pushdown is an optimization that is applied for access methods that access table data through indexes: ##range##, ##ref##, ##eq_ref##, ##ref_or_null##, and [[Batched Key Access]].
The idea is to check part of the WHERE condition that refers to index fields (we call it //Pushed Index Condition//) as soon as we've accessed the index. If the //Pushed Index Condition// is not satisfied, we won't need to read the whole table record.
Starting in [[mariadb-533-release-notes|MariaDB 5.3.3]], Index Condition Pushdown is **on** by default. To disable it, set its optimizer_switch flag like so:
<<code lang='sql'>>
SET optimizer_switch='index_condition_pushdown=off'
<</code>>
When Index Condition Pushdown is used, EXPLAIN will show "Using index condition":
<<code lang='sql'>>
MariaDB [test]> explain select * from tbl where key_col1 between 10 and 11 and key_col2 like '%foo%';
+----+-------------+-------+-------+---------------+----------+---------+------+------+-----------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+-------+---------------+----------+---------+------+------+-----------------------+
| 1 | SIMPLE | tbl | range | key_col1 | key_col1 | 5 | NULL | 2 | Using index condition |
+----+-------------+-------+-------+---------------+----------+---------+------+------+-----------------------+
1 row in set (0.01 sec)
<</code>>
== The idea behind index condition pushdown
In disk-based storage engines, making an index lookup is done in two steps, like shown on the picture:
{{index-access-2phases}}
Index Condition Pushdown optimization tries to cut down the number of full record reads by checking whether index records satisfy part of the WHERE condition that can be checked for them:
{{index-access-with-icp}}
How much speed will be gained depends on
- How many records will be filtered out
- How expensive it was to read them
The former depends on the query and the dataset. The latter is generally bigger when table records are on disk and/or are big, especially when they have blobs.
== Example speedup
I used DBT-3 benchmark data, with scale factor=1. Since the benchmark defines very few indexes, we've added a multi-column index (index condition pushdown is usually useful with multi-column indexes: the first component(s) is what index access is done for, the subsequent have columns that we read and check conditions on).
<<code lang='sql'>>
alter table lineitem add index s_r (l_shipdate, l_receiptdate);
<</code>>
The query was to find big (l_quantity > 40) orders that were made in January 1993" that took more than 25 days to ship:
<<code lang='sql'>>
select count(*) from lineitem
where
l_shipdate between '1993-01-01' and '1993-02-01' and
datediff(l_receiptdate,l_shipdate) > 25 and
l_quantity > 40;
<</code>>
EXPLAIN without Index Condition Pushdown:
<<code lang='sql'>>
-+----------+-------+----------------------+-----+---------+------+--------+-------------+
| table | type | possible_keys | key | key_len | ref | rows | Extra |
-+----------+-------+----------------------+-----+---------+------+--------+-------------+
| lineitem | range | s_r | s_r | 4 | NULL | 152064 | Using where |
-+----------+-------+----------------------+-----+---------+------+--------+-------------+
<</code>>
with Index Condition Pushdown:
<<code lang='sql'>>
-+-----------+-------+---------------+-----+---------+------+--------+------------------------------------+
| table | type | possible_keys | key | key_len | ref | rows | Extra |
-+-----------+-------+---------------+-----+---------+------+--------+------------------------------------+
| lineitem | range | s_r | s_r | 4 | NULL | 152064 | Using index condition; Using where |
-+-----------+-------+---------------+-----+---------+------+--------+------------------------------------+
<</code>>
The speedup was:
* Cold buffer pool: from 5 min down to 1 min
* Hot buffer pool: from 0.19 sec down to 0.07 sec
== Status variables
There are two server status variables
<<style class="darkheader-nospace-borders">>
|= Variable name |= Meaning
| <<code>>Handler_icp_attempts<</code>> | Number of times pushed index condition was checked
| <<code>>Handler_icp_match<</code>> | Number of times the condition was matched
<</style>>
That way, the value <<code>>Handler_icp_attempts - Handler_icp_match<</code>> shows the number records that the server did not have to read because of Index Condition Pushdown.
== See Also
* [[what-is-mariadb-53|What is MariaDB 5.3]]
* [[http://dev.mysql.com/doc/refman/5.6/en/index-condition-pushdown-optimization.html|Index Condition Pushdown]] in MySQL 5.6 manual (MariaDB's and MySQL 5.6's Index Condition Pushdown implementations have the same ancestry so are very similar to one another).
