GROUPBY GROUPING SETS((col1, col2), (col1, col3))
ROLLUP 对分组字段（或者表达式）从最详细级别到最顶级别计算聚合计数。ROLLUP的参数是一个有序分组字段列表，它计算从右向左各个级别的聚合。例如 ROLLUP(c1, c2, c3) 会为下列分组条件计算聚集：
(c1, c2, c3) (c1, c2) (c1) ()
CUBE 为分组字段的所有组合计算聚合。例如 CUBE(c1, c2, c3) 会计算一下聚合：
(c1, c2, c3) (c1, c2) (c2, c3) (c1, c3) (c1) (c2) (c3) ()
GROUPING SETS 指定对那些字段计算聚合，它可以比ROLLUP和CUBE更精确地控制分区条件。
6. 窗口函数
窗口函数可以实现在结果集的分组子集上的聚合或者排名函数，例如 sum(population) over (partition by city)。窗口函数功能强大，性能优异。因为它在数据库内部进行计算，避免了数据传输。
?
窗口函数row_number()计算一行在分组子集中的行号，例如row_number() over (order by id)。
? ?
如果查询计划显示某个表被扫描多次，那么通过窗口函数可能可以降低扫描次数。 窗口函数通常可以避免使用自关联。
7. 列存储和行存储
列存储亦即同一列的数据都连续保存在一个物理文件中，有更高的压缩率，适合在款表中对部分字段进行筛选的场景。
需要注意的是：若集群中节点较多，而且表的列也较多，每个节点的每一列将会至少产生一个文件，那么总体上将会产生比较多的文件，对表的DDL操作就会比较慢。在和分区表使用时，将会产生更多文件，甚至可能超过linux的文件句柄限制，要尤其注意。
?
行存储：如果记录需要update/delete，那么只能选择非压缩的行存方式。对于查询，如果选择的列的数量经常超过30个以上的列，那么也应该选择行存方式。
? 列存储：如果选择列的数量非常有限，并且希望通过较高的压缩比换取海量数据查询时的较好的IO性能，那么就应该选择列存模式。其中，列存分区表，每个分区的每个列都会有一个对应的物理文件，所以要注意避免文件过多，导致可能超越linux上允许同时打开文件数量的上限以及DDL命令的效率很差。
8. 函数和存储过程
虽然支持游标但是，尽量不要使用游标方式处理数据，而是应该把数据作为一个整体进行操作。
9. 索引使用
?
如果是从超大结果集合中返回非常小的结果集（不超过5%），建议使用BTREE索引（非典型数据仓库操作）
? ? ?
表记录的存储顺序最好与索引一致，可以进一步减少IO（好的index cluster） where条件中的列用or的方式进行join，可以考虑使用索引 键值大量重复时，比较适合使用bitmap索引
有关索引使用的测试见GP索引调优测试–基本篇和GP索引调优测试–排序篇。
10. NOT IN
? ?
在gp4.3中已经进行了优化，采用hash left anti semi join进行连接。 以下只针对gp4.1及之前
o 有not in的SQL，都会采用笛卡尔积来执行，采用nested join，效率极差 o not in==》改用left join去重后的表关联来实现 o 例子 o
select * from test1 where col1 not in (select col2 from test1)
改为
select * from test1 a left join (select col2 from test1 group bycol2) b on a.col1=b.col2 where b.col2 is null
运行时间由30多秒提升至92毫秒。
11. 聚合函数太多
?
一条SQL中聚合函数太多，而且可能由于统计信息不够详细或者SQL太负责，错选hashaggregate来执行，导致内存不足。
? 解决方法：
o 拆分成多个SQL来执行，减少hashaggregate使用的内存
o 执行enable_hashagg=off，把hashaggregate参数关掉，强制不采用。将会采
用groupaggregate，这样排序时间会长一些，但是内存可控，建议采用这种方式比较简单。
12. 资源队列
数据写入、查询分别使用不同的用户，GP创建用户时为不同用户指定不同的资源队列。
13. 其它优化技巧
? ? ?
用group by对distinct改写，因为DISTINCT要进行排序操作 用UNION ALL加GROUP BY的方式对UNION改写
尽量使用GREENPLUM自身提供的聚合函数和窗口函数去完成一些复杂的分析