Interesting Properties（以下简称IP）用来表述在对生成的计划进行分析时一些可能对优化产生重要影响的属性。网络上关于IP的资料并不多，但在Flink的论文里多次出现，Flink在它的一些论文中声明其借鉴自《Goetz Graefe. The Volcano Optimizer Generator- Extensibility and Efficient Search》（以下简称Volcano或Volcano的论文）和它的改进版《Goetz Graefe. The cascades framework for query optimization》（以下简称cascades或cascades的论文）中的优化技术。但是在另一些论文中声明其借鉴自《Pat Selinger, Access Path Selection in a Relational Database Management System》（以下简称System R的优化器论文）这一论文中的“Interesting Ordering”。其实，在这三篇论文中IP只在cascades的论文中出现过一次。
通过一些资料，本人揣测一下IP的由来。Pat Selinger在上面提到的那篇System R的优化器论文中提到的是“Interesting Ordering”（以下简称IO）。IO是为了弥补（或者说修正）“dynamic programming”（动态规划，以下简称DP）技术在寻找成本最低的方案上的一些不足。
IBM的System R是第一个成功的关系型数据库项目，该项目开创了很多经典技术，优化器便是其中之一。Pat Selinger在开发System R时提出了DP和IO这两个重要算法和思想，影响了所有后续的数据库优化器的设计和实现。
我们以一个例子来说明IO的作用，比如在多表join时，DP会首先搜索最底层问题的最优方案，比如访问某个表的最佳访问方案。不同访问方法本身的代价有高有低，DP仅考虑这些方法本身的代价，找到成本最低的那个。但是，不同方法产生的结果集存在一种特性，这种特性会影响后续执行的效率，它就是数据的ordering，即是否排序。如果用户的查询语句中有“order by”，那么比较两种扫描代价的时候就不能简单地比较各自的成本，比如，一个候选计划A，其扫描代价小并产出了乱序的结果集；另一个候选计划B，其扫描代价高并产出了排序的结果，那么这两种方案谁更高效，在当前阶段尚未可知。比如，数据被取出后送到Join操作符，一般有三种可能的join方案：nest loop join（以下简称NLJ）、sort merge join（以下简称SMJ）和 hash join（以下简称HJ）。其中SMJ的代价往往是最小的，但是它却要求输入的数据必须排序，因此如果底层返回的数据是乱序的，优化器便不能选择SMJ，而必须从HJ和NLJ中选择一个。因此上面的A、B两种候选计划，虽然A本身的代价小些，但是B却可以产出排序的数据时，仅仅基于DP显然错过了最佳方案SMJ。
所以引入了IO，每一个方案都保留一项属性（即“ordering”）。如果数据是排序的，就将该属性设置为true；否则设置为false。而DP在比较两个方案时，如果拥有不同属性，则不能简单地认为A比B好，而是两个都作为最优解保留下来。这样，上层的优化过程就不会错过更优的方案了。
后来随着优化器的发展，人们发现不仅ordering很重要，还有其他一些特性也很重要，比如partition信息在分布式执行过程中也是很重要的参考指标。因此后来IO思想被衍生为”Physical Property“（以下简称PP，来自Vlocano的论文），并在其他的优化器技术中得到了更加广泛的应用。而这个词也广泛出现在上面提到的Goetz的两篇论文里，当然与之对应的还有“Logical Property”。
虽然没有考证，但IP可看作是Flink对IO和PP的一个中和。而且从优化器模块的代码实现来看，除了有InterestingProperties这一定义还有LocalProperties、GlobalProperties以及PartitioningProperty等类型定义。这里的property（或properties）表示对优化产生影响的属性，而前面的修饰词则阐述了它们是什么类型的属性。无论如何，IP是一种思想，理解其作用即可。
原文发布时间为：2017-02-13
本文作者：vinoYang
本文来自云栖社区合作伙伴CSDN博客，了解相关信息可以关注CSDN博客。
