PostgreSQL estimates row counts from collected statistics; poor estimates can lead to poor join and scan choices. Tuning combines current statistics, query expressions that available indexes can support, bounded result work, realistic data distributions, and measured system evidence. Configuration changes come after query, schema, statistics, and workload causes are understood.
The planner has summaries, not future knowledge. Correlated columns—tenant and status, country and postal code—can fool independence assumptions. ANALYZE samples values; statistics targets trade planning accuracy for collection/catalog cost.
For correlated predicates, extended statistics can capture dependencies or distinct combinations:
Verify that important estimates improve; do not create statistics indiscriminately.
Query design matters: avoid applying a function to an indexed column unless an expression index matches; use half-open time ranges; avoid fetching unused large columns; pre-aggregate before multiplicative joins; bound sorts and context.
Tenant-specific retrieval distributions are highly skewed. One tenant may have 100 chunks and another 10 million. Record per-stage candidate counts and plans. AI latency budgets need query time separated from embedding/model time, and token budgets need result bounds independent of SQL speed.
Create skewed tenant/status data. Record estimate/actual ratios before and after statistics changes. Verify plan stability for common and rare parameters, then remove the experimental statistics if it provides no measurable benefit.
Generate correlated organization/status data and evaluate extended statistics.
Acceptance criterion: you report estimate ratios and plan effects, not just elapsed time, and retain the statistics only if evidence supports it.