7.4 分区裁剪的两种时机

分区裁剪依据 partition bounds 与可证明的条件移除无关 child，不依赖分区键上存在 index。裁剪减少要规划/执行的子计划，却不会自动让分区内访问高效，也不消除启动时取得的 relation lock。

7.4.1 规划时裁剪与常量条件

四个季度分区上：

WHERE occurred_on = date '2025-05-15'

planner 在规划时知道常量，证明只有 Q2 可能匹配；JSON 计划只出现 ch07_event_probe_2025q2。适合裁剪的条件通常直接用 partition key 与符合 bounds operator class 的等值/范围比较。

语义等价不代表 planner 能证明。例如：

WHERE date_trunc('month', occurred_on::timestamp)
      = timestamp '2025-05-01'

函数包住 partition key，当前实验计划出现四个 child；每个分区再 filter。正确性不变，裁剪合同丢失。修复通常把 API 月份转换成明确半开范围：

WHERE occurred_on >= date '2025-05-01'
  AND occurred_on <  date '2025-06-01'

不要为追求裁剪擅自改写时区/边界语义；先证明新 predicate 与业务时间合同等价。

7.4.2 执行时裁剪、参数化节点与通用计划

generic prepared plan 在 planning 时不知道 $1，仍可在 executor initialization 获得参数后裁剪：

SET plan_cache_mode = force_generic_plan;
PREPARE p(date) AS
SELECT event_id
FROM shop_private.ch07_event_probe
WHERE occurred_on = $1;

EXPLAIN (ANALYZE, FORMAT JSON)
EXECUTE p(date '2025-05-15');

本章结果只执行 Q2，并报告 Subplans Removed: 3。初始化期移除的 partition 不再显示为完整 child；真正 execution parameter（例如 nested loop inner 参数）改变时还可重复裁剪，此时要看各 child loops 与 (never executed)。

“计划文本里有 Append”不等于所有分区都被扫描。要联合看：

• plan 中保留的 child；
• Subplans Removed；
• each child loops/actual rows/buffers；
• planning time 与 partition 数；
• 执行开始时仍可能取得的 locks。

7.4.3 分区父表统计需要显式 ANALYZE

autovacuum 会处理普通 leaf partition，却不处理不直接存 tuple 的 partitioned parent；child 变化也不会触发 parent 的 inheritance statistics 更新。查询父表若依赖整体统计，应在首次装载及分布显著变化后显式：

ANALYZE shop_private.ch07_event_probe;

默认会同时递归分析 partitions。大型 hierarchy 要评估采样、lock 与窗口；可用 ONLY 控制范围，但要理解自己放弃了什么统计。

实验先只 ANALYZE 四个 leaf，父表 pg_stats 行数为 0；显式分析父表后变为 4。数字 4 对应当前四列，不是通用 golden；稳定结论是 0→非零。监控 leaf last_autoanalyze 不能替代检查 parent statistics。

7.4.4 产出裁剪生效与失效的计划对照

运行：

export PGSERVICEFILE=/absolute/private/path/pg_service.conf
export PGSERVICE=pg36-admin
cd static/labs/ch07
export PG36_EVIDENCE_DIR="$PWD/evidence/ch07/partition-$(date -u +%Y%m%dT%H%M%SZ)"

./task.sh setup
./task.sh partition
cat "$PG36_EVIDENCE_DIR/plan-summary-partition.txt"

注意两个 action 若复用同一 evidence directory，后者会更新 manifest；正式 release 建议直接 all 保持单一 bundle。稳定摘要：

partition_counts=constant:1,wrapped:4,generic:1
partition_parent_stats=0->4

原始三个 JSON 才是审计证据。analyzer 递归收集实际 relation nodes，并要求 generic Subplans Removed>=3；不 grep 本地化文本。

这个实验不证明业务表应该分区。它只证明已有 partition design 下，条件形状、参数可见性与统计维护怎样影响 planner。是否分区仍要回到 retention、规模、约束和运维收益，遵守 PREF-PART-003。

上一节：统计信息与估算偏差 · 返回本章目录 · 下一节：参数、缓存计划与计划漂移 · 查看全书目录 · 查看索引中心