Details
-
Task
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
None
-
None
Description
We need counters to track Index Condition Pushdown. In particular, we need to track
- how many times pushed-index-condition check was performed
- how many times the check filtered out a record
(Note: We had also an idea to change counters so that
1. index tuple reads
2. full record reads
are counted separately. Implementation of that task does not kill the need
for counters aimed specifically at index condition pushdown)
Proposed counter names:
Handler_pushed_index_cond_checks N
Handler_pushed_index_cond_filtered N
Implementation to filter a record
- Every storage engine invokes ${engine_name}_idx_cond_func(). That function
has access to SQL layer, so it should be easy for it to bump up counters.
- Batched Key Access uses a different function. Will need to perform counting there, too.
FYI: MySQL-5.6 has a feature called "InnoDB monitor" which exports there four counters:
select name, count from information_schema.innodb_metrics where name like "icp%";
name count
icp_attempts 1
icp_no_match 0
icp_out_of_range 1
icp_match 0
grep for MONITOR_ICP in the source or look at user interface in:
mysql-test/suite/innodb/t/innodb_monitor.test
Attachments
Issue Links
- blocks
-
-
- Closed
-
Activity
Need also to check 5.6: they have some counters there. we need to be compatible.
| Field | Original Value | New Value |
|---|---|---|
| Workflow | jira [ 10627 ] | defaullt [ 10735 ] |
| Fix Version/s | 5.3.5 [ 10400 ] |
| Assignee | Rasmus Johansson [ ratzpo ] | Sergei Petrunia [ psergey ] |
| Description |
We need counters to track Index Condition Pushdown. In particular, we need to track - how many times pushed-index-condition check was performed - how many times the check filtered out a record (Note: We had also an idea to change counters so that 1. index tuple reads 2. full record reads are counted separately. Implementation of that task does not kill the need for counters aimed specifically at index condition pushdown) Proposed counter names: Handler_pushed_index_calls N Handler_pushed_index_filtered N Implementation to filter a record - Every storage engine invokes ${engine_name}_idx_cond_func(). That function has access to SQL layer, so it should be easy for it to bump up counters. - Batched Key Access uses a different function. Will need to perform counting there, too. |
We need counters to track Index Condition Pushdown. In particular, we need to track - how many times pushed-index-condition check was performed - how many times the check filtered out a record (Note: We had also an idea to change counters so that 1. index tuple reads 2. full record reads are counted separately. Implementation of that task does not kill the need for counters aimed specifically at index condition pushdown) Proposed counter names: Handler_pushed_index_cond_checks N Handler_pushed_index_cond_filtered N Implementation to filter a record - Every storage engine invokes ${engine_name}_idx_cond_func(). That function has access to SQL layer, so it should be easy for it to bump up counters. - Batched Key Access uses a different function. Will need to perform counting there, too. |
| Assignee | Sergei Petrunia [ psergey ] | Oleksandr Byelkin [ sanja ] |
| Status | Open [ 1 ] | In Progress [ 3 ] |
| Description |
We need counters to track Index Condition Pushdown. In particular, we need to track - how many times pushed-index-condition check was performed - how many times the check filtered out a record (Note: We had also an idea to change counters so that 1. index tuple reads 2. full record reads are counted separately. Implementation of that task does not kill the need for counters aimed specifically at index condition pushdown) Proposed counter names: Handler_pushed_index_cond_checks N Handler_pushed_index_cond_filtered N Implementation to filter a record - Every storage engine invokes ${engine_name}_idx_cond_func(). That function has access to SQL layer, so it should be easy for it to bump up counters. - Batched Key Access uses a different function. Will need to perform counting there, too. |
We need counters to track Index Condition Pushdown. In particular, we need to track - how many times pushed-index-condition check was performed - how many times the check filtered out a record (Note: We had also an idea to change counters so that 1. index tuple reads 2. full record reads are counted separately. Implementation of that task does not kill the need for counters aimed specifically at index condition pushdown) Proposed counter names: Handler_pushed_index_cond_checks N Handler_pushed_index_cond_filtered N Implementation to filter a record - Every storage engine invokes ${engine_name}_idx_cond_func(). That function has access to SQL layer, so it should be easy for it to bump up counters. - Batched Key Access uses a different function. Will need to perform counting there, too. FYI: MySQL-5.6 has a feature called "InnoDB monitor" which exports there four counters: select name, count from information_schema.innodb_metrics where name like "icp%"; name count icp_attempts 1 icp_no_match 0 icp_out_of_range 1 icp_match 0 grep for MONITOR_ICP in the source or look at user interface in: mysql-test/suite/innodb/t/innodb_monitor.test |
| Status | In Progress [ 3 ] | Open [ 1 ] |
| Status | Open [ 1 ] | In Progress [ 3 ] |
| Resolution | Fixed [ 1 ] | |
| Status | In Progress [ 3 ] | Closed [ 6 ] |
| Workflow | defaullt [ 10735 ] | MariaDB v2 [ 45049 ] |
| Workflow | MariaDB v2 [ 45049 ] | MariaDB v3 [ 65605 ] |
| Workflow | MariaDB v3 [ 65605 ] | MariaDB v4 [ 131901 ] |
Typical function:
ICP_RESULT index_cond_func_maria(void *arg)
{ if (h->compare_key2(h->end_range) > 0) return ICP_OUT_OF_RANGE; /* caller should return HA_ERR_END_OF_FILE already */ }{
ha_maria h= (ha_maria)arg;
if (h->end_range)
//!! counting Handler_pushed_index_calls should be done here (that is: after out-of-range-check)
return h->pushed_idx_cond->val_int() ? ICP_MATCH : ICP_NO_MATCH;
//!! counting Handler_pushed_index_filtered should be done here if we got ICP_NO_MATCH
}