การนำการแบ่งพาร์ทิชันแบบแฮชไปใช้

Range partitioning suits dates; list partitioning suits known categories. But what if you just want even distribution with no natural boundaries?

That is where hash partitioning shines.

Hash partitioning applies a hash function to the partition key and assigns each row to a partition based on the remainder, spreading rows evenly.

Create the parent table partitioned BY HASH on a key column.

Each partition declares a modulus and remainder. With modulus 4 you create four partitions, remainders 0 to 3.

You must create partitions covering every remainder, otherwise some rows have nowhere to go.

On insert, PostgreSQL hashes user_id, takes the remainder modulo 4, and stores the row in the matching partition automatically.

Because hashing scatters values, partitions stay roughly equal in size, avoiding the hot-partition problem that range partitioning can suffer.

The modulus equals your number of partitions. Pick it up front, since changing partition count later requires redistributing data.

Create indexes on the parent and PostgreSQL propagates them to all partitions, keeping lookups fast within each shard.

• Range: ordered boundaries (dates, numbers)
• List: discrete known values (regions)
• Hash: even spread when no natural grouping exists

Hash partitioning gives no partition pruning for range queries on the key, since values are scattered. It helps point lookups and write distribution, not range scans.

Test your hash partitioning knowledge.

Hash partitioning spreads rows evenly across a fixed number of partitions using MODULUS and REMAINDER on a hashed key.

It is ideal for balancing writes and point lookups when there is no natural range or list, but it cannot prune partitions for range queries on the key.