PostgreSQL 在复杂查询中的可塑性是很高的，但是如果在网上去找相关的例子，我尝试了一下，比较少。这里突然有一个想法，想验证一下postgresql 的复杂查询到底如何，自己做几个例子来和大家分享一下。
下面是一个实例的数据库，是一个DVD租借的公司的数据库案例
、
根据这个数据库做出一些查询，尽量的提高查询的复杂的方法来看看POSTGRESQL 在复杂查询，OLAP中的到底性能如何。
1 查出伦敦这个城市的DVD租借在 2017-02月份中的租借的DVD的每个会员的月话费。
具体的语句撰写和结果，从语句的撰写看，里面包含了子查询，数值的转换，字段的合并，连接等等虽然还不是很复杂
下面是这个查询的执行计划，可以从中看到POSTGRESQL 优化查询的方式也是多种多样的。查询时间在0.002432秒
2 根据演员出演电影的数量，进行名次的排列
相关的执行计划
在postgresql 中的子查询，在查询中是需要优化的，优化中子查询是要进行提升条件的，一般一个子查询要提升需要以下一些要求
1 子查询必须是一个子查询树，
2 子查询中不能包含聚集操作，窗口函数，GROUP操作等
3 子查询中的条件仅仅是两个表之间进行关系界定的条件，针对子查询本身的条件将不能进行子查询的条件提升
下面这两条语句的结果是一样的，执行计划基本上也是一样，但语句的写法是很不一样的。
但如果我们在换一种写法，不使用子查询，达到同样的结果，
从执行计划中，明显可以看到执行计划变得简洁，并且执行的时间也有下降。
试验的版本是 VERSION 11.2 ,这里参与计算的表数据量在几十万，经过验证上面三种查询的写法，最后一种没有子查询的写法，占优势。
我们在换一个实验如果我们在join 中使用子查询，或者不使用子查询使用where条件后期排除数据那种方式更好
产生的执行计划，除了最后一个在细微的地方不一样，其他的costing 等位置是一样。
（此处省略第一个语句的执行计划，因为和第二个语句的执行计划一致，下图是2 ，3 语句的执行计划，不同处已经蓝色标记）
原来想的是，中间的执行计划会站到便宜，最上边的是最差的，但实际当中，上面的执行计划并没有很差，至少从执行计划上看 POSTGRESQL在处理语句并行进行执行计划的处理上，还是很强的，因为不同的语句最后的解释的处理过程是基本一致的，说明查询分析器很稳定。
最后类似条件中，意义一样写法不一样的情况下，POSTGRESQL 也会根据集合的概念，将其写法统一化
从执行计划看，明显是走了第一种语句的写法，将第二种语句改变为第一种语句的写法。
当然这样的测试还应该继续，并且更深入，只有这样才能找到数据库引擎在某种配置下，SQL 撰写的 较优的方式（因为执行计划么有最好，只有更好）
