# Partitioned Table Overview
+ Multiple child tables (partition) compose a parent table
+ Partition types: **`RANGE`**, **`LIST`**, **`HASH`**, and **`KEY`**
+ Optimizer aware the partitions and they are transparent to query statements
+ Execution plans can **prune** table to filter out irrelevant partitions to reduce I/O operations
+ Isolates and speeds up certain maintenance operations by specifying partitions explicitly, for example:
  + **`ANALYZE`** statements
  + **`DELETE`** and **`UPDATE`** rows

------------------------------------------------------------------------------
Similar to indexes, table partitions in databases are data structures designed to accelerate data retrieval operations. When a query statement is executed, table partitions enable the database to quickly find data that meets the query conditions. This leads to time savings as opposed to scanning the entire table sequentially (`TableFullScan`), thus enhancing query efficiency.

In the TiDB database, the data rows belonging to the same partition are mapped to one or more `TiKV Regions` at the storage level, which can be spread across different TiKV instances.

The optimizer ignores partitions with no query result data when executing queries; this is known as partition pruning.

You can host partitions on separate TiKV nodes to boost parallel I/O throughput for multi-row seeks or to store frequently-accessed data on TiKV nodes with high-end storage using SQL placement rules. 

TiDB supports explicit partition clause for `SELECT`, `DELETE`, `INSERT`, and `UPDATE` statements. For example, the following statement selects only those rows in partitions `p3` and `p5` that match the `WHERE` condition: `SELECT * FROM t PARTITION (p3, p5) WHERE c = 192`.