我不知道为什么在这个例子中逻辑计划没有得到正确的评估。
我更深入地研究了flink基代码，并检查了calcite在计算/估计对象中查询的行数时的情况。出于某种原因，对于任何表源，它总是返回100。
实际上，在flink中，在创建程序计划的过程中，对于每个转换后的规则，tableenvironment.run火山规划器称之为火山规划器类。规划器试图通过调用relmetadataquery.getrowcount来优化和计算一些估算
我通过创建一个失败的测试重现了这个错误，该测试应该Assert0为关系表的行计数，但它总是返回100。
为什么会这样？有人对这个问题有答案吗？
1条答案
按热度按时间fkvaft9z1#
在当前版本（1.7.11919年1月）中，flink的关系api（表api和sql）不尝试估计基表的基数。因此，方解石使用其默认值100。
这对于过滤器和投影下推之类的基本优化非常有效，目前已经足够了，因为flink还没有对连接进行重新排序。
为表注入基数估计的唯一方法是通过
ExternalCatalog.