Why it matters
Bad partition design is the top cause of Hive performance problems. Too few partitions means every query scans everything. Too many partitions overwhelms the metastore. Getting this right is worth days of engineering time.
The architecture
A partitioned table has one or more partition columns. Each partition is a subdirectory named like col=value. Multi-level partitioning nests directories: year=2026/month=07/day=05.
Query planner does partition pruning: filters on partition columns eliminate non-matching partitions before scan. Only matching partition directories are read.
How it works end to end
Partition metadata lives in the metastore. Each partition has an entry in PARTITIONS with its location. Query planning consults these entries to compute prune sets.
Static partitioning: INSERT specifies partition values explicitly. Dynamic partitioning: values come from query output; enables efficient partitioned inserts from unpartitioned sources.
Partition pruning happens during query compilation. Bad statistics or non-pushable predicates defeat pruning.