# 分区裁剪的两种时机

LLMS 索引： [llms.txt](/llms.txt)

---

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

## 7.4.1 规划时裁剪与常量条件 {#item-7-4-1}

四个季度分区上：

```sql
WHERE occurred_on = date '2025-05-15'
```

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

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

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

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

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

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

## 7.4.2 执行时裁剪、参数化节点与通用计划 {#item-7-4-2}

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

```sql
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` {#item-7-4-3}

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

```sql
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 产出裁剪生效与失效的计划对照 {#item-7-4-4}

运行：

```bash
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。稳定摘要：

```text
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`。

---

[上一节：统计信息与估算偏差](../03/) · [返回本章目录](../) · [下一节：参数、缓存计划与计划漂移](../05/) ·
[查看全书目录](/toc/) · [查看索引中心](/indexes/)