# Execute and Read (Continue...)


![left](./student-guide/diagram/05-Read-execution-01-02.png)

------------------------------------------------------------
Second, the execution plan goes through the DistSQL module and transforms it into simple select queries one by one, that is, those that may contain complex operators such as JOIN, SUBQUERY, etc., that involve many tables are abstracted and wrapped into multiple single-table query computation tasks. It is then sent as a request to the coprocessor of the lower TiKV via the TiKV Client. Note that one request may involve queries for multiple regions on multiple TiKV, so the DistSQL module can send request in parallel.

When TiKV receives a request, it first constructs a snapshot (snapshot), that is, a data structure at a specific point in time. The queried data must be closest to this point in time, but not newer than this point in time. The query is then processed according to different request. Currently, there are two ways:
  - A class is a simple query that specifies a row or rows to query, and runs in the Storage Read Pool.
  - The other type is complex aggregate computation, range query (e.g. TableScan, IndexScan, Selection, TopN, Limit, PartialAggregation, etc., which can be pushed down to TiKV nodes for execution), such request run on the coprocessor Read Pool.

Starting with TiKV 5.0, by default, all read request are queried through the unified thread pool UnifyRead Pool module in the TiKV node, as shown in the figure.

Next, the thread pool will read data from RocksDB KV. For the RocksDB KV reading of TiKV, please refer to “RocksDB - Query”, “Read Data - ReadIndex Read”, “Read Data - Lease Read” in Lesson 03: TiKV /Local Read” and “Read Data - Follower Read”.

At this point, the data request by the DistSQL module has been read from the TiKV it is in.