我不同意该问题当做非问题处理。

问题单中比较奇怪的现象是，表t0为空，且在经过analyze之后，通过explain可以观察到其估算的总行数为 2149，这和实际情况差距较大，如果能正确的估算t0的行数，应该不会出现物化的情况。

通过验证 往t0 表插入一行数据，再删除，再analyze，可得到正确的行数估算结果，不会出现物化：

所以问题的关键在于为什么对新创建的空表做analyze和插入数据再删除数据的空表做analyze之后，行数估算结果不一样。

通过gdb代码可找到如下关键路径：

注释说得很清楚，不再赘述。 最终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 系统表的逻辑对于绝大部分场景不会造成性能损耗，影响可控。

尊敬的社区开发者：

你们好。以下问题已分析为非问题并已在评论区答复，enable_material 物化参数开启影响了优化器的代价估算，关闭该参数（set enable_material = off;）即可解决，详细测试结果见问题单评论。由于联系不到提单人，现根据社区issue处理规范进行公示，7天后无反馈将进行关闭处理：

https://gitcode.com/opengauss/openGauss-server/issues/7159

如有问题，可联系邮件回复或在issue下面回复，感谢。