我不同意该问题当做非问题处理。 问题单中比较奇怪的现象是，表t0为空，且在经过analyze之后，通过explain可以观察到其估算的总行数为 2149，这和实际情况差距较大，如果能正确的估算t0的行数，应该不会出现物化的情况。 [cid:image002.png@01DBE454.3A70AC10] 通过验证 往t0 表插入一行数据，再删除，再analyze，可得到正确的行数估算结果，不会出现物化： [cid:image001.png@01DBE455.4C97EE20] 所以问题的关键在于为什么对新创建的空表做analyze和插入数据再删除数据的空表做analyze之后，行数估算结果不一样。 通过gdb代码可找到如下关键路径： [cid:image003.png@01DBE456.7D7324A0] 注释说得很清楚，不再赘述。 最终2149的行数估算就是因为这里默认估算10个page导致的。为什么插入一行再删除就没问题呢？因为插入一行再删除，analyze之后，relpages为1，不为0，astore的特点，死元组仍存在page上。 同时注释也说明了，通过 rd_rel->relpages == 0 来判断表是否被vacuum/analyze过，这可能导致一个真正的空表被误判（此即问题单中的场景）。 我建议修复这个潜在的误判场景，在这个if判断最后加一个条件，通过搜索 pg_statistic_history 系统表，判断表是否真正被 vacuum/analyze过。 由于 pg_statistic_history 系统表没有syscache，且不被经常使用，分析潜在的性能影响。首先仍保持前面的if条件，所以只有满足如下条件才会需要查询pg_statistic_history 系统表： 1． Curpages < 10，即磁盘上的物理存储文件page数量 < 10，只有很小的表才有可能出现 2． Rel->rd_rel->relages == 0，要么是表从来没有被 vacuum/analyze过，要么是表真的没有数据 3． 后面两个if条件不太重要，忽略 可知此种场景在实际业务中发生的概率较小，新增一个搜索 pg_statistic_history 系统表的逻辑对于绝大部分场景不会造成性能损耗，影响可控。 发件人: douxin (A) <douxin5@huawei.com> 发送时间: 2025年6月23日 11:49 收件人: community@opengauss.org; sqlengine@opengauss.org; qa@opengauss.org 抄送: hanlizhu <hanlizhu@huawei.com>; liuchangfeng <liuchangfeng2@huawei.com> 主题: [Community] 【问题单公示】OpenGuass处理包含空表的join查询时，短路处理不完善 尊敬的社区开发者： 你们好。以下问题已分析为非问题并已在评论区答复，enable_material 物化参数开启影响了优化器的代价估算，关闭该参数（set enable_material = off;）即可解决，详细测试结果见问题单评论。由于联系不到提单人，现根据社区issue处理规范进行公示，7天后无反馈将进行关闭处理： https://gitcode.com/opengauss/openGauss-server/issues/7159 如有问题，可联系邮件回复或在issue下面回复，感谢。
