Partitioning

Software Engineering / 22 Sep 2026 / 6 min read

Rendezvous Hashing Limits Key Movement During Membership Changes

Rendezvous Hashing Limits Key Movement During Membership Changes A partitioning rule has two jobs that can pull in different directions. It should spread keys across available nodes, and it should avoid moving most keys when that node set changes. A simple modulo rule handles the first job well for a stable cluster but performs poorly at the second. Rendezvous hashing, also called highest-random-weight hashing, assigns every key a deterministic score for every eligible node. The node with the highest score owns the key. Adding or removing a node changes only the comparisons involving that member, so keys with unaffected winners keep their placement.

Software Engineering Distributed Systems

Software Engineering / 21 Sep 2026 / 6 min read

Consistent Hashing Limits Key Movement During Membership Changes

Consistent Hashing Limits Key Movement During Membership Changes A simple hash partition often looks sufficient: owner = hash(key) % node_count With four nodes, every key maps to one of four remainders. The problem appears when the membership changes. Moving from four nodes to five changes the modulus, so a large fraction of keys select a different owner even though only one node was added.

Software Engineering Distributed Systems

Software Engineering / 20 Sep 2026 / 6 min read

Consistent Hashing Limits Key Movement When Nodes Change

Partitioning by hash(key) % N is simple when the node count stays fixed. The arithmetic becomes disruptive when N changes. Moving from four nodes to five changes the divisor, so many keys select a different remainder even though only one node joined. Consistent hashing changes the mapping. Keys and nodes are placed in the same circular hash space. A key belongs to the first node encountered in a chosen direction around the ring. Adding or removing a node changes ownership only for ranges adjacent to that membership change.

Software Engineering Distributed Systems

Database / 15 Sep 2026 / 5 min read

PostgreSQL Execution-Time Partition Pruning Removes Subplans

A PostgreSQL plan can contain partition subplans that never execute. When a partition key predicate depends on a value unavailable during planning, the executor can apply partition pruning after that value becomes available and skip partitions whose bounds cannot match it. This behavior matters for prepared statements, parameterized nested-loop joins, and predicates fed by subqueries. In these cases, the set of relevant partitions can become narrower after the planner has already produced the plan.

PostgreSQL Database

Database / 14 Sep 2026 / 5 min read

PostgreSQL Partition Pruning Skips Unneeded Tables

A partitioned PostgreSQL table can represent many physical child tables behind one logical relation. A query against the parent does not necessarily scan every child. When a predicate conflicts with a partition’s bounds, PostgreSQL can remove that partition from the plan or execution path. This behavior is partition pruning. It depends on the partition key and partition bounds rather than an index on the key. The distinction matters because pruning decides which relations can be ignored before access methods inside the remaining relations become relevant.

PostgreSQL Database

Database / 14 Sep 2026 / 5 min read

PostgreSQL Partition Pruning Removes Unneeded Partitions

A partitioned PostgreSQL table can expose one logical relation while storing rows across many physical partitions. A query that constrains the partition key does not necessarily need to inspect each child relation. Partition pruning uses the declared partition bounds to remove partitions that cannot contain matching rows. Pruning is separate from index selection. It determines which partitions remain relevant; the planner can then choose a sequential scan, index scan, bitmap scan, or another access path inside each surviving partition.

PostgreSQL Database

Software Engineering / 12 Sep 2026 / 9 min read

Consistent Hashing: Limit Key Movement as Nodes Change

Distributed systems often need a deterministic answer to a simple question: given a key, which node should own it? A cache cluster may route each object key to one server. A storage service may assign each partition to a shard. A worker pool may send all events for the same account to the same processor. The routing rule must be stable enough that clients agree, yet flexible enough to handle nodes joining and leaving.

Software Engineering Distributed Systems