// src/backend/executor/execMain.c, ExecutorStart()
void ExecutorStart(QueryDesc *queryDesc, int eflags) {
    // 1. 初始化执行状态（EState）
    // 2. 为计划树中每个节点调用 ExecInitNode()
    // 3. 为 expression tree 编译 opcode（EEO）
    ExecInitPlan(queryDesc, estate, eflags);
    ...
}

// src/backend/executor/execMain.c, ExecutorRun()
void ExecutorRun(QueryDesc *queryDesc,
                 ScanDirection direction,
                 uint64 count, bool execute_once) {
    // 循环调用 ExecProcNode(planstate->planTree) 直到：
    // - 返回 NULL（没数据了）
    // - 达到 count 条
    // - execute_once 为 true（只跑一次，如 INSERT）
}

// src/backend/executor/execMain.c, ExecutorFinish()
void ExecutorFinish(QueryDesc *queryDesc) {
    // 执行收尾：触发器、WITH CHECK OPTION 校验等
}

// src/backend/executor/execMain.c, ExecutorEnd()
void ExecutorEnd(QueryDesc *queryDesc) {
    // 对每个节点调用 ExecEndNode() 释放资源
    ExecEndPlan(queryDesc->planstate, estate);
}
```text

四个阶段的调用关系：

### 1.2 ExecInitNode：递归初始化计划树

`ExecInitNode()` 根据节点类型（plan node 的 `type` 字段）分发到具体的 `ExecInit*` 函数：

```c
// src/backend/executor/execProcnode.c, ExecInitNode()
PlanState *ExecInitNode(Plan *node, EState *estate, int eflags) {
    switch (nodeTag(node)) {
        case T_SeqScan:
            return ExecInitSeqScan((SeqScan *) node, estate, eflags);
        case T_IndexScan:
            return ExecInitIndexScan((IndexScan *) node, estate, eflags);
        case T_HashJoin:
            return ExecInitHashJoin((HashJoin *) node, estate, eflags);
        case T_NestLoop:
            return ExecInitNestLoop((NestLoop *) node, estate, eflags);
        case T_MergeJoin:
            return ExecInitMergeJoin((MergeJoin *) node, estate, eflags);
        case T_Hash:
            return ExecInitHash((Hash *) node, estate, eflags);
        case T_Agg:
            return ExecInitAgg((Agg *) node, estate, eflags);
        case T_Sort:
            return ExecInitSort((Sort *) node, estate, eflags);
        // ... 还有几十种
    }
}

// src/include/executor/executor.h
static inline TupleTableSlot *
ExecProcNode(PlanState *node) {
    return node->ExecProcNode(node);
}
```text

这是一个函数指针调用——每个算子注册自己的 `ExecProcNode` 实现。以 SeqScan 为例：

```c
// src/backend/executor/nodeSeqscan.c
static TupleTableSlot *SeqNext(SeqScanState *node) {
    HeapScanDesc scandesc = node->ss.ss_currentScanDesc;
    EState *estate = node->ss.ps.state;
    TupleTableSlot *slot = node->ss.ss_ScanTupleSlot;

    for (;;) {
        // 从 heap 中读取下一个 tuple
        HeapTuple tuple = heap_getnext(scandesc, direction);

        if (tuple == NULL) return NULL;  // 没有更多行了

        // 把 heap tuple 放入 slot
        ExecStoreHeapTuple(tuple, slot, false);

        // 应用 scan qual（filter 条件下推到 scan 层）
        if (!ExecQual(node->qual, econtext)) continue;

        return slot;
    }
}

// src/include/executor/hashjoin.h
typedef struct HashJoinTableData {
    int            nbuckets;           // bucket 数量（2 的幂）
    int            log2_nbuckets;      
    int            nbatch;             // batch 数量（hash join 溢出分区数）
    int            curbatch;           // 当前处理的 batch
    
    // batched hash join 的内存管理
    struct HashMemoryChunk *chunks;    // 链表分配的内存块
    
    // bucket 数组
    HashJoinTuple  *buckets;           // buckets[0..nbuckets-1]，每个 bucket 是 tuple 链表
    
    // batch 文件（溢出到磁盘）
    BufFile       **innerBatchFile;    // 每个 batch 的 inner 临时文件
    BufFile       **outerBatchFile;    // 每个 batch 的 outer 临时文件
    
    // 统计
    Size           spaceUsed;          // hash 表当前使用内存
    Size           spaceAllowed;       // 内存上限 = work_mem × hash_mem_multiplier  (PG 15+)
    Size           spacePeak;          // 内存使用峰值
} HashJoinTableData;
```text

Hash Join 用 **Grace Hash Join（hybrid hash join）** 作为磁盘溢出策略：当 inner 表太大无法全部放入 `work_mem × hash_mem_multiplier` 时，PG 用两个 hash 函数——第一个 hash 分 batch，第二个 hash 分 bucket。当前 batch 在内存中，其他 batch 的 inner 行写入临时文件；outer 行也按 batch 分流到临时文件。每个 batch 完成后再加载下一个 batch。观察 `EXPLAIN ANALYZE` 中的 `Buckets:`、`Batches:`、`Memory Usage:` 可以判断是否发生了磁盘溢出。

### 2.3 Hash Join 的执行示例

```sql
EXPLAIN (ANALYZE, BUFFERS, COSTS OFF)
SELECT * FROM orders o JOIN customers c ON o.customer_id = c.id;

// src/include/executor/execExpr.h
typedef struct ExprState {
    NodeTag     tag;
    Expr       *expr;                  // 原始表达式树（调试用）
    ExprEvalStep *steps;               // 编译后的 opcode 数组
    int         steps_len;             // 数组长度
    int         steps_alloc;           // 已分配长度
    Datum      *results;               // 中间结果数组
    int         ressize;               // 结果数组大小
    bool        resnull;               // 最终结果为 NULL
    Datum       resvalue;              // 最终结果值
    struct MemoryContext *eval_mcontext;  // 求值用的 memory context
} ExprState;
```bash

### 3.2 Opcode 指令集

EEO 定义了约 30 种 opcode，每种对应一个表达式操作：

```c
// src/include/executor/execExpr.h
typedef enum ExprEvalOp {
    EEOP_DONE,                  // 结束标记
    
    // 常量
    EEOP_CONST,                 // 把常量压入结果
    EEOP_NULL_IF_NULL,          // 一行中某列为 NULL 则整个表达式为 NULL
    
    // 变量
    EEOP_INNER_VAR,             // 从 inner slot 读列值
    EEOP_OUTER_VAR,
    EEOP_SCAN_VAR,
    EEOP_INNER_SYSVAR,
    EEOP_OUTER_SYSVAR,
    EEOP_SCAN_SYSVAR,
    
    // 函数调用
    EEOP_FUNCEXPR,              // 调用 C 函数（如 int4eq, texteq 等）
    EEOP_FUNCEXPR_STRICT,       // 带 STRICT 语义（任一参数 NULL 则结果为 NULL）
    
    // 布尔运算
    EEOP_BOOL_AND_STEP_FIRST,   // AND 短路求值
    EEOP_BOOL_AND_STEP_LAST,
    EEOP_BOOL_OR_STEP_FIRST,
    EEOP_BOOL_OR_STEP_LAST,
    EEOP_BOOL_NOT_STEP,
    
    // CASE
    EEOP_CASE_TESTVAL,
    EEOP_MAKE_READONLY_CASE_TESTVAL,
    EEOP_CASE_WHEN,
    
    // 跳转与条件
    EEOP_JUMP,                  // 无条件跳转
    EEOP_JUMP_IF_NOT_TRUE,      // 条件跳转（AND/OR 短路用）
    EEOP_JUMP_IF_NULL,          // 判定 NULL 后跳转
    
    // 数组、行类型、XML、JSON 等
    EEOP_ARRAYEXPR,
    EEOP_ARRAYCOERCE,
    EEOP_ROWEXPR,
    EEOP_ROWCOMPARE_STEP,
    
    // 其他
    EEOP_ASSIGN_TMP,            // 临时变量赋值
    EEOP_ASSIGN_TMP_MAKE_RO,
    
    // 子查询
    EEOP_PARAM_EXEC,
    EEOP_PARAM_EXTERN,
    
    // 哈希——用于 hash join / hash agg
    EEOP_HASHED_SCALAR,         // 对单列做 hash
    EEOP_HASHED_SCALAR_NULLS,
    
    // 聚合
    EEOP_AGGREF,
    EEOP_GROUPING_FUNC,
    EEOP_WINDOW_FUNC,
    
    // 子计划
    EEOP_SUBPLAN,
    EEOP_ALTERNATIVE_SUBPLAN,
} ExprEvalOp;

// src/backend/executor/execExpr.c, ExecInitExprRec()
// 递归编译表达式树为 step 数组（简化）
static void ExecInitExprRec(Expr *node, ExprState *state,
                            Datum *scratch, int *scratch_idx) {
    switch (nodeTag(node)) {
        case T_Var:
            // 列引用 → EEOP_INNER_VAR / EEOP_OUTER_VAR / EEOP_SCAN_VAR
            ExecPushVarStep(state, (Var *) node);
            break;

        case T_Const:
            // 常量 → EEOP_CONST
            ExecPushConstStep(state, (Const *) node);
            break;

        case T_OpExpr:
            // 二元操作符 → 先编译左子树 → EEOP_FUNCEXPR_STRICT
            ExecInitExprRec(lfirst(list_head(op->args)), ...);
            ExecInitExprRec(lsecond(list_head(op->args)), ...);
            ExecPushFuncExprStep(state, op->opfuncid, op->opresulttype);
            break;

        case T_BoolExpr:
            // AND/OR → EEOP_BOOL_AND_STEP_FIRST 等
            // 实现短路求值：AND 遇到 false 跳过剩余子表达式
            ExecPushBoolExprSteps(state, (BoolExpr *) node);
            break;

        case T_CaseExpr:
            // CASE WHEN ... THEN ... ELSE ...
            ExecPushCaseSteps(state, (CaseExpr *) node);
            break;

        // ... 更多类型
    }
}
```text

以 `x + y > 10 AND z IS NOT NULL` 为例，编译后可能生成如下 opcode 序列：

```text
1. EEOP_OUTER_VAR          // 读 x 列值 → scratch[0]
2. EEOP_OUTER_VAR          // 读 y 列值 → scratch[1]
3. EEOP_FUNCEXPR_STRICT    // int4pl(scratch[0], scratch[1]) → scratch[2]
4. EEOP_CONST              // 常量 10 → scratch[3]
5. EEOP_FUNCEXPR_STRICT    // int4gt(scratch[2], scratch[3]) → result
6. EEOP_BOOL_AND_STEP_FIRST  // AND 左分支：如果 false，跳到步骤 9
7. EEOP_OUTER_VAR          // 读 z 列值 → scratch[0]
8. EEOP_BOOL_AND_STEP_LAST   // AND 右分支：返回 IS NOT NULL 结果
9. EEOP_DONE               // 结束

// src/backend/executor/execExprInterp.c, ExecInterpExpr()
// 核心解释循环（简化）
static pg_attribute_always_inline void
ExecInterpExpr(ExprState *state, ExprContext *econtext, bool *isnull) {
    ExprEvalStep *op = state->steps;
    int nsteps = state->steps_len;
    Datum *results = state->results;

    for (;;) {
        switch (op->opcode) {
            case EEOP_CONST:
                *op->resvalue = op->d.constval.value;
                *op->resnull  = op->d.constval.isnull;
                op++;
                break;

            case EEOP_OUTER_VAR: {
                int attnum = op->d.var.attnum;
                SlotGetSomeAttrs(econtext->ecxt_outertuple, attnum);
                *op->resvalue = econtext->ecxt_outertuple->tts_values[attnum];
                *op->resnull  = econtext->ecxt_outertuple->tts_isnull[attnum];
                op++;
                break;
            }

            case EEOP_FUNCEXPR_STRICT: {
                FunctionCallInfo fcinfo = op->d.func.fcinfo_data;
                // ... 检查是否有 NULL 参数 ...
                fcinfo->isnull = false;
                *op->resvalue = op->d.func.fn_addr(fcinfo);  // 调用 C 函数
                *op->resnull  = fcinfo->isnull;
                op++;
                break;
            }

            case EEOP_BOOL_AND_STEP_FIRST:
                if (*op->resnull || !DatumGetBool(*op->resvalue)) {
                    // AND 短路：跳转到最后一个 AND step 之后
                    op = &state->steps[op->d.boolexpr.jumpdone];
                } else {
                    op++;
                }
                break;

            case EEOP_JUMP:
                op = &state->steps[op->d.jump.jumpdone];
                break;

            case EEOP_DONE:
                if (isnull) *isnull = state->resnull;
                return;  // 求值结束
        }
    }
}
```text

`ExecInterpExpr()` 被声明为 `always_inline` + `static`——编译器会将它内联到调用点，消除函数调用开销。整个循环在一个大的 `switch` 中按 opcode 跳转，没有递归调用，没有表达式树的指针追踪。

执行 overhead 的比较：

| 方式 | 每次求值的函数调用次数 | L1i cache 行为 |
|------|----------------------|---------------|
| 递归解释表达式树 | 每个节点至少一次 `ExecEvalExpr()` 调用 | 函数调用导致指令 cache 跳跃 |
| EEO opcode 循环 | 零次额外调用（在一次循环内） | opcode 循环紧凑，指令 cache 友好 |

### 3.5 JIT 的区别

EEO 是**解释执行**opcode（switch-case 分发），而 JIT（第 13 章主题）是用 LLVM 把 opcode 序列编译成**机器码**——连 switch-case 的分发开销都消除了。两者的关系是：EEO 编译出 opcode → JIT 再把 opcode 序列 JIT 成 native code。第 13 章会详细展开。

---

## 四、TupleTableSlot：行的三种承载方式

执行器中的每一行数据都封装在 `TupleTableSlot` 中。它不是简单的指针——它抽象了三种不同物理形态的 tuple 存储，让上层算子（Hash Join、Aggregate）不必关心下层传上来的是 heap tuple 还是虚拟 tuple。

### 4.1 三种 Slot 类型

```c
// src/include/executor/tuptable.h
typedef enum TupleTableSlotType {
    T_TupleTableSlot_Virtual,  // 虚拟 slot：数据在 tts_values[] / tts_isnull[] 数组中
    T_TupleTableSlot_Minimal,  // 最小化元组：只有列值，没有系统列（xmin/xmax 等）
    T_TupleTableSlot_Heap,     // 堆元组：完整的 HeapTupleData（含 xmin/xmax/ctid）
} TupleTableSlotType;

// src/include/executor/tuptable.h
struct TupleTableSlot {
    NodeTag         tag;
    uint16          tts_nvalid;        // tts_values[] 中已填充的列数
    const TupleTableSlotOps *tts_ops;  // 虚函数表（根据实际 slot 类型不同）
    TupleDesc       tts_tupleDescriptor;  // 列描述（列名、类型、长度）
    Datum          *tts_values;        // 列值数组（Datum 是 PG 的值容器类型）
    bool           *tts_isnull;        // 列的 NULL 标志数组
    MemoryContext   tts_mcxt;          // 此 slot 的内存上下文
    ItemPointerData tts_tid;           // tuple 的物理位置 (block, offset)
    int             tts_tableOid;      // 来源表的 OID
};
```text

`tts_ops` 虚函数表是关键——不同类型的 slot 有不同的 `tts_ops`，实现了不同的 `slot_getallattrs()`、`slot_getsomeattrs()` 等操作。

### 4.2 Virtual Slot：最轻量

虚拟 slot 的数据直接存储在 `tts_values[]` 和 `tts_isnull[]` 数组中——没有对应的 heap tuple。表达式求值的结果、aggregate 的中间结果、函数扫描输出都使用 virtual slot。

```c
// 典型用法：表达式求值结果用 virtual slot 承载
TupleTableSlot *slot = ExecInitExtraTupleSlot(estate, tupdesc, &TTSOpsVirtual);
slot->tts_values[0] = computed_value;
slot->tts_isnull[0] = false;
ExecStoreVirtualTuple(slot);  // 标记为有效

// 从 buffer pool 读取到 heap slot
HeapTuple tuple = heap_getnext(scandesc, ForwardScanDirection);
ExecStoreHeapTuple(tuple, slot, false);  // false = 不拷贝，直接引用 buffer 页
```text

`ExecStoreHeapTuple(tuple, slot, false)` 不做数据拷贝——slot 的 `tts_values[]` 指针直接指向 buffer 页内的数据。这意味着在 `ReleaseBuffer()`（unpin）之前必须消费完 slot 内容，否则悬空指针。

### 4.4 Minimal Slot：用于 Hash 表

Hash Join 在构建 hash 表时，inner 行需要被存储到 hash 表的 tuple 链表中——但此时 PG 不需要系统列（xmin/xmax）。Minimal slot 只保存用户列值，用于 hash 表存储和 hash join 匹配时的连接键抽取。

```c
// src/backend/executor/nodeHash.c
// hash join build 阶段：将 heap slot 转成 minimal tuple 存入 hash 表
ExecCopySlotMinimalTuple(slot);  // 提取用户列，丢掉系统列

// 从 slot 中取第 N 列的值
slot_getattr(TupleTableSlot *slot, int attnum, bool *isnull);

// 把所有列值填充到 tts_values[] / tts_isnull[]（惰性解构）
slot_getallattrs(TupleTableSlot *slot);

// 只填充一部分列（只填充需要的，惰性）
slot_getsomeattrs(TupleTableSlot *slot, int attnum);

// 把 slot 内容物化成 heap tuple（如果是 virtual/minimal，需要构造 HeapTupleData）
ExecFetchSlotHeapTuple(TupleTableSlot *slot, bool materialize, bool *shouldFree);
```text

惰性解构（lazy deforming）是性能优化：从 heap page 读出的 tuple 以紧凑格式存储（列值不是对齐的数组），不需要立即"解构"成 `tts_values[]` 数组。`slot_getattr()` 在第一次访问某列时才解构，后续访问复用结果。

---

## 五、执行器与 Buffer Manager 的交互

执行器不直接读写磁盘——它通过 Buffer Manager 访问页面。以 Seq Scan 为例：

```c
// src/backend/access/heap/heapam.c, heap_getnext()
HeapTuple heap_getnext(TableScanDesc sscan, ScanDirection direction) {
    HeapScanDesc scan = (HeapScanDesc) sscan;
    
    for (;;) {
        // 当前页面用完 → 读下一页
        if (scan->rs_inited && !heap_page_is_all_visible(...)) {
            // ... 处理 VM 检查和 pin 操作 ...
        }
        
        page = BufferGetPage(scan->rs_cbuf);  // 获取 pinned buffer 的页面指针
        lineoff = ItemPointerGetOffsetNumber(&scan->rs_ctup.t_self);
        
        // 扫描页面中的 ItemId 数组，找下一个有效 tuple
        lines = PageGetMaxOffsetNumber(page);
        for (; lineoff <= lines; lineoff++) {
            itemId = PageGetItemId(page, lineoff);
            if (!ItemIdIsNormal(itemId)) continue;
            
            // 设置返回 tuple 的位置
            scan->rs_ctup.t_self = ItemPointer(block, lineoff);
            
            // heap_getnext 不拷贝数据——返回指针指向 buffer 页
            // buffer 的 pin 由执行器框架在释放 slot 时处理
            return &scan->rs_ctup;
        }
        
        // 本页扫描完，unpin 旧页面，pin 新页面
        scan->rs_cblock++;  // 下一页
    }
}

SELECT pid, state, wait_event_type, wait_event, query_start, LEFT(query, 120)
FROM pg_stat_activity
WHERE state != 'idle'
ORDER BY query_start;
```text

关键 `wait_event_type` 的解读：

| wait_event_type | 典型 wait_event | 含义 | 下一步 |
|-----------------|----------------|------|--------|
| `Lock` | `relation` / `transactionid` / `tuple` | 等待 heavyweight lock（表锁/行锁/事务锁） | 查 `pg_locks` + `pg_blocking_pids()` |
| `LWLock` | `buffer_content` / `WALWrite` / `lock_manager` | 等待轻量级锁 | 看具体 LWLock 名称判断热点模块 |
| `IO` | `DataFileRead` / `WALRead` / `WALWrite` | 等待物理 IO | 查 `pg_stat_io` / `iostat` 确认磁盘是否有问题 |
| `BufferPin` | `BufferPin` | 其他 backend 持有一个 buffer 的 pin 太久 | 查谁持有了这个 buffer——通常意味着有人在 buffer 页数据上做了长时间操作 |
| `Client` | `ClientRead` | 等待客户端发来下一条 SQL | 这不是 hang，是客户端没在发数据（idle in transaction 的典型表现） |
| `Timeout` | `PgSleep` | `pg_sleep()` 等主动休眠 | 查 SQL 里是否有 `pg_sleep` |
| `Activity` | `ArchiverMain` / `AutoVacuumMain` 等 | 辅助进程的主循环等待 | 属于正常状态 |

常见误诊："查询 hang 住了，`wait_event=ClientRead`"——这不叫 PG hang 住，是客户端没有发下一条 SQL。如果一条连接 `state='idle in transaction'` 且 `wait_event='ClientRead'`，它是在等客户端提交/回滚——但这期间它持有的锁不释放，其他查询会被阻塞在 `wait_event_type='Lock'`。

### 6.2 锁等待链追踪

当一个查询 `wait_event_type='Lock'` 时，下一步是找到它在等谁的锁：

```sql
-- 查询所有未授予的锁及其阻塞者
SELECT
    blocked.pid              AS blocked_pid,
    blocked.query            AS blocked_query,
    blocking.pid             AS blocking_pid,
    blocking.query           AS blocking_query,
    blocked.wait_event_type,
    blocked.wait_event
FROM pg_stat_activity blocked
CROSS JOIN LATERAL unnest(pg_blocking_pids(blocked.pid)) AS blocking_pid
JOIN pg_stat_activity blocking ON blocking.pid = blocking_pid
WHERE blocked.state = 'active';

WITH RECURSIVE lock_chain AS (
    -- 初始：找到等待锁的会话
    SELECT pid, pg_blocking_pids(pid) AS blockers, 1 AS level
    FROM pg_stat_activity
    WHERE wait_event_type = 'Lock'
    
    UNION ALL
    
    -- 递归：查找阻塞者的阻塞者
    SELECT a.pid, pg_blocking_pids(a.pid), lc.level + 1
    FROM pg_stat_activity a
    JOIN lock_chain lc ON a.pid = ANY(lc.blockers)
    WHERE lc.level < 10  -- 防止环
)
SELECT DISTINCT pid, blockers, level FROM lock_chain ORDER BY level;
```text

同时需要看锁的类型：

```sql
SELECT
    l.pid, l.mode, l.granted, l.locktype,
    l.relation::regclass AS table_name
FROM pg_locks l
JOIN pg_stat_activity a USING (pid)
WHERE l.pid = ANY(pg_blocking_pids(<hang_pid>))
   OR l.pid = <hang_pid>;

-- 如果查询条件是 a > 100 AND b > 100，
-- 而 a 和 b 存在相关性（大数据 a 往往对应大数据 b），
-- 单列统计会严重低估过滤率。
-- 解决方案：
CREATE STATISTICS s1 ON a, b FROM your_table;
ANALYZE your_table;
```text

**参数化查询的通用计划问题**：
```sql
-- PREPARE 后的参数化查询，PG 可能使用通用计划（generic plan）
-- 固定使用一组代价估算，不考虑参数值的分布差异。
SHOW plan_cache_mode;  -- 检查是用 'auto' 还是 'force_generic_plan'

-- 第一步：定位 hang 住的原因
SELECT pid, state, wait_event_type, wait_event, query
FROM pg_stat_activity
WHERE pid = <hang_pid>;

-- 第二步：如果是等锁，追踪锁等待链
SELECT unnest(pg_blocking_pids(<hang_pid>));

-- 第三步：看锁的细节
SELECT locktype, mode, granted, relation::regclass
FROM pg_locks WHERE pid IN (<hang_pid>, <blocker_pid>);

-- 第四步：如果 garented=false 且 mode='AccessExclusiveLock'，
-- 查阻塞这条 DDL 的所有 backend
SELECT pid, state, query, xact_start
FROM pg_stat_activity
WHERE pid = ANY(pg_blocking_pids(<ddl_pid>));

-- 第五步：如果没在等锁，而是在 IO 等待
-- 查看 EXPLAIN 输出定位哪个节点产生大量 IO
-- 再用 pg_stat_io 确认是不是磁盘瓶颈
SELECT * FROM pg_stat_io WHERE backend_type = 'client backend';

-- 补救措施（仅在确认安全时使用）
SELECT pg_cancel_backend(<pid>);       -- 取消查询（不 kill 连接）
SELECT pg_terminate_backend(<pid>);    -- 终止连接（回滚事务）
```text

---

## 七、实验：观察执行器行为

### 7.1 用 GDB 追踪 ExecProcNode

```bash
# 1. 开一个 psql session
psql -c "SELECT pg_backend_pid();"
# 假设输出 12345

# 2. 在另一个终端 attach
gdb -p 12345

# 3. 设置断点
(gdb) break ExecProcNode
(gdb) continue

# 4. 在 psql 中执行一条查询，GDB 会在每次 ExecProcNode 调用时停住
# 通过 bt 看调用栈，追踪是哪一层算子在被调用
(gdb) bt
# #0  ExecProcNode ... 
# #1  ExecNestLoop ...
# #2  ExecProcNode ...
# #3  ExecSort ...
# ...

-- 先把 work_mem 调到极低，强制 hash join 溢出
SET work_mem = '64kB';

-- 制造一张大表
CREATE TABLE t_big AS SELECT generate_series(1, 100000) AS id, 
                              md5(random()::text) AS data;

CREATE TABLE t_small AS SELECT generate_series(1, 1000) AS id;

ANALYZE t_big; ANALYZE t_small;

-- 执行 hash join
EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM t_big b JOIN t_small s ON b.id = s.id;
```text

输出会显示 `Batches:` 远大于 1，`Memory Usage:` 接近 64kB，说明发生了磁盘溢出。`Buffers:` 的 `read` 计数会显著增加——因为每个 batch 都要从临时文件重读数据。

对比正常模式：
```sql
SET work_mem = '64MB';
-- 同样查询，Batches: 1