# `IndexReader` Data Aggregator and `IndexRangeScan` Operator

+ **`IndexRangeScan`** scans the index with the specified range
+ **`IndexReader`** aggregates the data retrieved from the index using the underlying operators
+ **`access object`** shows the parent table and the particular index
+ For example, the table `employees` is not accessed, the index on the `first_name` column is the only object accessed to complete the query 

```6
tidb> EXPLAIN SELECT first_name FROM employees WHERE first_name IN ('Parto','Sumant');
+--------------------+---------+------------+---------------------------------------------------+----------------------------------------------------------------+
| id                 | estRows | task       | access object                                     | operator info                                                  |
+--------------------+---------+------------+---------------------------------------------------+----------------------------------------------------------------+
| IndexReader_6      | 472.87  | root       |                                                   | index:IndexRangeScan_5                                         |
| └─~!@IndexRangeScan_5 | 472.87  | cop[tikv]  | table:employees, index:idx_first_name(first_name) | range:["Parto","Parto"], ["Sumant","Sumant"]@!~, keep order:false |
+--------------------+---------+------------+---------------------------------------------------+----------------------------------------------------------------+
2 rows in set (0.00 sec)
```

------------------------------------------------------------------------------
In the slide, we observed that the condition `first_name IN ('Parto', 'Sumant')` can be efficiently managed using the secondary index `idx_first_name`. We also noted that the `SELECT` statement is querying the indexed column `first_name` from this secondary index. Consequently, the entire query can be handled by scanning the secondary index `idx_first_name` on the TiKV nodes to retrieve the index key values that meet the condition, which are then returned to the TiDB Server. This allows the query to be executed entirely through the index, avoiding direct table access. Although this approach may not match the efficiency of point lookups (such as Point_Get or Batch_Point_Get), it is still quite effective and is therefore ranked as the second-best in terms of performance.

In this scenario, we examine two operators: `IndexRangeScan` and `IndexReader`. The `IndexRangeScan` operator handles index scanning, which is a common method for accessing secondary indexes. This operator is associated with the task column `cop[tikv]`, indicating that TiKV nodes use coprocessors for index reading. The `IndexReader` operator, on the other hand, represents the process where TiKV nodes return the index values that match the query conditions. These values are then aggregated by the TiDB Server to produce the final result set. This operation is carried out solely based on the index values and is linked to the task column root, signifying that it is performed on the TiDB Server.

We can also classify this query as utilizing a covering index. This is because all the required column values for matching rows and returning results are contained within the index. Consequently, the TiDB Server does not need to access the employees table to retrieve this information.