Greenplum查询计划评估

如何看查询计划?

　　若一个查询表现出不好的性能，查看查询计划可能有助于找到问题点。下面是 一些须要查看的东西： 

计划中是否有一个操做花费时间超长？

　　查询计划中是否有一个操做花费 了大部分的处理时间？例如，若是一个索引扫描比预期的时间超长，也许 该索引已经处于过时状态，须要考虑重建索引。还可临时尝试使用enable_ 之类的参数查看是否能够强制选择不一样的计划(可能会更好的效果)，这些 参数能够设置特定的查询计划操做为开启或关闭状态。 

规划器的评估是否接近实际状况？

　　执行EXPLAIN ANALYZE查看规划器 评估的记录数与真实运行查询操做返回的记录数是否一致。若是差别巨大， 可能须要在TABLE相关的COLUMN上收集更多的统计信息。 

选择性强的条件是否较早出现？

　　选择性强的条件应该被较早应用，从而使 得在计划树中上传的记录更少。若是查询计划在选择性评估方面没有对查 询条件做出正确的判断，可能须要在TABLE相关的COLUMN上收集更多 的统计信息。相关信息可查看”维护数据库统计信息”章节。也能够尝试调 整SQL语句WHERE子句的顺序。 

规划器是否选择了最佳的关联顺序？

　　如查询使用多表关联，须要确保规划 器选择了选择性最好的关联顺序。那些能够消除大量记录的关联应在更早 的被执行，从而使得在计划树中上传的记录更少。若是规划器没有选择最 佳的关联顺序，能够尝试设置join_collapse_limit=1并在SQL语句中构造特 定的关联顺序，从而能够强制规划器选择指定的关联顺序。还能够尝试在 TABLE相关的COLUMN上收集更多的统计信息。相关信息可查看”维护数

规划器是否选择性的扫描分区表？

　　若是使用了分区，规划器是否值扫描了 查询条件匹配的相关子表？父表的扫描返回0条记录(本该如此，由于父表 不包含任何数据)。做为显示选择性扫描分区查询计划的例子。 

规划器是否合适的选择了HASH聚合与HASH关联操做？

　　HASH操做一般 比其余类型的关联和聚合要快。记录在内存中的比较排序比磁盘快。要使 用HASH操做，必须有足够的工做内存用以放置评估的记录。对于特定才 查询能够尝试增长工做内存来查看是否可以得到更好的性能。若是可能， 为该查询执行EXPLAIN ANALYZE，将能够获得哪些操做缓存到磁盘(由 于工做内存不足致使)，多少的工做内存被使用，以及须要多少内存以保证 不缓存到磁盘。例如：

Work_mem used: 23430K bytes avg, 23430K bytes max (seg0).

Work_mem wanted: 33649K bytes avg, 33649K bytes max (seg0) to lessen

workfile I/O affecting 2 workers.

须要注意的是wanted信息只是一个提示，基于写出工做文件的量是不精确的。 须要的最小work_mem可能会比提示的值或多或少一些。