PostgreSQL查询计划中的“计划行：0”是什么意思？

此查询显示查询计划中的计划行：0

CREATE TABLE EMP (
   EMP_ID CHAR(4),
   EMP_NAME VARCHAR(200)
);
INSERT INTO EMP VALUES ( '1000', 'JOHN DOE' );
INSERT INTO EMP VALUES ( '1001', 'ALAN SMITHEE' );
INSERT INTO EMP VALUES ( '1002', 'JANE DOE' );
EXPLAIN (ANALYZE, FORMAT JSON)
   SELECT * FROM EMP WHERE EMP_ID = NULL;

结果:

[ { "Plan": {
   "Node Type": "Result",
   "Parallel Aware": false,
   "Startup Cost": 0.00,
   "Total Cost": 0.00,
   "Plan Rows": 0,
   "Plan Width": 438,
   "Actual Startup Time": 0.001,
   "Actual Total Time": 0.001,
   "Actual Rows": 0,
   "Actual Loops": 1,
   "One-Time Filter": "false"
},
"Planning Time": 0.023,
"Triggers": [ ],
"Execution Time": 0.011 } ]

此查询计划中的计划行：0表示什么

PostgreSQL没有扫描任何记录，因为EMP_ID=NULL总是false。 PostgreSQL扫描了EMP表，因为统计数据可能与实际的表内容不同。

---

分析将每次扫描表，因为您的条件始终为false，所以它将始终返回0个计划行。如果在不截断表的情况下继续插入行，您将看到随着行数的增加，成本开始上升，这是因为检查where条件花费了额外的时间

从文件中：

rows值有点棘手，因为它不是计划节点处理或扫描的行数，而是节点发出的行数。这通常小于扫描的数量，这是通过在节点上应用的任何WHERE子句条件进行过滤的结果。理想情况下，顶级行估计值将近似于查询实际返回、更新或删除的行数

根据链接文档中显示的示例：

请注意，EXPLAIN输出显示了作为附加到Seq Scan plan节点的过滤条件应用的WHERE子句。这意味着计划节点检查扫描的每一行的条件，并仅输出通过条件的行。由于WHERE子句，输出行的估计数已减少。但是，扫描仍然需要访问所有10000行，因此成本没有降低；事实上，它增加了10000*cpu操作员成本，准确地说，这反映了检查WHERE条件所花费的额外cpu时间

PostgreSQL检测到emp_id=NULL始终为false，因此它根本不扫描表，而是立即返回一个空结果

---

“Plan Rows”是估计的结果行数，为0，因为PostgreSQL知道不可能有结果行。通常，当PostgreSQL无法确定时，它会估计至少一个结果，以避免在估计不准确的情况下出现非常糟糕的计划。

此答案与问题无关。但：大多数人更喜欢使用explain ANALYSE，格式化文本或简单解释分析-JSON格式更适合通过工具等进行自动分析。