Query Planner on Nalar

PostgreSQL Join Collapse Bounds Planner Search

Tue, 15 Sep 2026 00:00:00 +0700

PostgreSQL can reorder many joins instead of treating SQL text order as a fixed execution sequence. That freedom gives the planner more candidate plans, but the search space grows rapidly as a query brings more relations into one join problem. Two planner settings, join_collapse_limit and from_collapse_limit, place boundaries on how aggressively PostgreSQL flattens query structure before it searches for a plan.

These limits are not execution-time row caps. They shape planner search. Changing them can alter planning time and can also alter the set of join orders available for consideration.

PostgreSQL Bitmap Scans Combine Index Results

Mon, 14 Sep 2026 00:00:00 +0700

A PostgreSQL query does not need a single index that represents every useful predicate. The planner can scan separate indexes, turn their matching tuple locations into bitmaps, combine those bitmaps, and then visit the required heap pages. This is the basis of bitmap index scans and Bitmap Heap Scan plans.

The mechanism sits between two familiar choices. A sequential scan reads the table broadly, while a plain index scan follows index entries to heap tuples as it encounters them. A bitmap plan first gathers locations, then performs heap access as a distinct phase.

PostgreSQL Extended Statistics Model Column Relations

Mon, 14 Sep 2026 00:00:00 +0700

PostgreSQL normally collects planner statistics for individual columns. That model works well when predicates can be estimated independently, but real schemas often contain related values. A country and region pair, a tenant identifier and status, or two derived date expressions can have distributions that single-column statistics cannot represent.

Extended statistics add a second layer of information across multiple columns or expressions. They do not create an access path and they do not change stored table data. Their role is narrower: provide the planner with a better model for cardinality estimation when values are related.

PostgreSQL Memoize Caches Parameterized Scan Results

Mon, 14 Sep 2026 00:00:00 +0700

A nested-loop join can execute its inner plan many times. When that inner plan is parameterized by values from the outer side, repeated outer values can trigger the same inner lookup again and again. PostgreSQL can place a Memoize node above the parameterized scan so a later lookup with the same parameter key can reuse rows already produced.

Memoization does not change join semantics and it does not create a persistent cache. It is an executor-level optimization attached to a particular query plan, with entries that exist only for that execution.

PostgreSQL Partition Pruning Removes Unneeded Partitions

Mon, 14 Sep 2026 00:00:00 +0700

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.