schema: review-report-v2
target: "CommitFest 7161: Apply extended statistics to join clause during parameterized path costing"
source: postgresql-master
slug: commitfest-7161-review
head: 061065e28f086e3e2d7191a7785b9f218b7976d8
base: 061065e28f086e3e2d7191a7785b9f218b7976d8
verdict: "ready-for-committer (test follow-up required)"
blocker_counts:
  verified: 0
  unverified: 0
coverage_requirement: required
coverage_status: measured

CommitFest 7161 Review: Apply Extended Statistics to Join Clause During Parameterized Path Costing

Author: Ilia Evdokimov (Tantor Labs) CommitFest: PG20-3 (2026-11-01 – 2026-11-30), patch 7161 Patch version: v1, +42 −3, 2 files Review date: 2026-10-08 Model: glm-5.2:cloud

Verdict

ready-for-committer (test follow-up required)

No BLOCKER findings. No correctness/security MAJOR findings. One test-only MAJOR (F-1: no regression tests for the new behavior). The patch is functionally correct and the author's repro confirms the intended behavior. The test gap should be addressed before commit.

Blocker split: verified=0, unverified=0

Patch Summary

The patch makes functional-dependency extended statistics applicable when costing parameterized base-relation paths. Previously, clauselist_selectivity_ext only applied extended stats when all clauses referenced a single relation (find_single_rel_for_clauses returned non-NULL). For a parameterized scan, clauses include join quals like t1.a = t2.b, so find_single_rel_for_clauses returns NULL and no extended stats were used — even though varRelid identifies the scanned relation.

Two coordinated changes:

1. src/backend/optimizer/path/clausesel.c:158-166 — when

use_extended_stats && rel == NULL && varRelid != 0, look up paramrel = find_base_rel(root, varRelid) and, if it is an RTE_RELATION with stats, call dependencies_clauselist_selectivity on it, multiplying the result into s1.

1. src/backend/statistics/dependencies.c:743-788 —

dependency_is_compatible_clause now allows up to two varnos (was BMS_SINGLETON), and in the OpExpr branch, when neither arg is pseudoconstant, accepts Var(relid) = Var(other-single-rel) and treats the other relation's Var as a pseudoconstant.

Runtime Verification

Built PostgreSQL with meson+ninja in a disposable scratch build with coverage instrumentation (b_coverage=true). Ran the author's repro and additional scenarios against a scratch PostgreSQL instance:

• Without stats: rows=2 per probe (independence assumption: 1/1000 × 1/100)
• With dependency stats: rows=200 per probe (matching actual 200 rows/probe)
• LEFT JOIN: also benefits (rows=200 with stats)
• 3-way joins with outer joins: no crash, correct estimates
• Plan change: Index Scan → Bitmap Heap Scan due to improved cost estimate

No crash observed in any tested scenario (inner join, LEFT JOIN, RIGHT JOIN, FULL JOIN, 3-way joins with outer joins, OR clauses).

Changed-Code Coverage

Counter epoch: fresh disposable gcov epoch at HEAD Execution lane: host-disposable (passed)

Coverage Totals

Uncovered Lines (7)

Uncovered Branches (17)

Excluded Changed Coordinates

None — all changed lines have gcov coverage coordinates.

Non-Instrumented Changes

None — all changed files are C source files with coverage instrumentation.

Findings

CREATE TABLE dep_param_t1 (a int, b int, c int) WITH (autovacuum_enabled = off);
CREATE TABLE dep_param_t2 (a int, b int) WITH (autovacuum_enabled = off);
INSERT INTO dep_param_t1 SELECT i%100, i%100, i%100 FROM generate_series(1,1000) i;
INSERT INTO dep_param_t2 SELECT i, i FROM generate_series(0,99) i;
CREATE INDEX dep_param_t1_a_b_idx ON dep_param_t1 (a, b);
ANALYZE dep_param_t1, dep_param_t2;
SET enable_hashjoin = off; SET enable_mergejoin = off; SET enable_bitmapscan = off;
EXPLAIN (COSTS ON)
SELECT * FROM dep_param_t2, dep_param_t1
WHERE dep_param_t1.a = dep_param_t2.a AND dep_param_t1.b = dep_param_t2.b;
CREATE STATISTICS dep_param_st (dependencies) ON a, b FROM dep_param_t1;
ANALYZE dep_param_t1;
EXPLAIN (COSTS ON)
SELECT * FROM dep_param_t2, dep_param_t1
WHERE dep_param_t1.a = dep_param_t2.a AND dep_param_t1.b = dep_param_t2.b;

RelOptInfo *paramrel = find_base_rel_noerr(root, varRelid);
if (paramrel && paramrel->rtekind == RTE_RELATION && paramrel->statlist != NIL)

Verification Summary

Repair Validation Summary

pgsql-hackers Thread Ledger

Thread: 7b1bd383-fa74-4c0e-a75a-52ff9c753750@tantorlabs.com Status: reconciled (3 messages)

Finding links:

• F-4: author-deferred (Vondra raised join-level estimation; author deferred to follow-up)
• F-7: refuted (refuted by verification)

Aggregated Test Plan

1. F-1 test (regress): src/test/regress/sql/stats_ext.sql — parameterized

join with functional dependencies, assert rows=1 → rows=10 transition. Covers clausesel.c:158-165 and dependencies.c:743-780.

1. F-2/F-3 repairs validated with the same test plus inner/LEFT/RIGHT join

scenarios — no regression.

Provenance / Model Routes

Residual Risk

• The patch treats the join-partner Var as a pseudoconstant, averaging over

its value distribution. This is a sound first-order approximation but may be less accurate for highly skewed join keys. The author acknowledges this and plans MCV/ndistinct as follow-up work.

• The scan-vs-join estimate inconsistency noted by Vondra (50 × 200 ≠ 98) is

not resolved by this patch and remains an open item for join-level estimation follow-up.

• The right-arg-is-relid path (lines 781-785) is unreachable through normal SQL

due to EC clause Var ordering normalization. This is defensive code that is correct but untestable through regression tests.

Maintainer CC

Tomas Vondra (reviewer of extended statistics code), as the thread reviewer.