1. 在完成大批量数据装载之后，针对目标表总是进行vacuum analyze操作。
2. 表的布局：
尽量把数据分布键放在最前面，如果是分区表，那么接下来是分区键，并且在此基础上建议按照数据类型宽度从大到小的顺序排列比如先8 byte的列，再4字节，再2字节。
3. 数据分布键的选择：
数据分布均匀是保证GP高效并行处理能力的基础。因此定义表时，如果选用HASH分布策略，保证数据分布均匀是获取高性能的关键所在。选择的依据遵从三大原则，第一个就是首先保证前面提到的所有节点数据存放是均匀的。第二，如果经常进行大表连接，那么尽量把连接键定义成数据分布键（如果多个列作为数据分布键，他们应该都出现在连接中，否则还是会造成无效广播），这样尽量减少无效的interconnect。第三，尽量保证where条件产生的结果集的存储也尽量是均匀的。
4. GREENPLUM同时支持行存和列存方式，那么到底该怎么选择？ 如果记录需要update/delete，那么只能选择非压缩的行存方式。对于查询，如果选择的列的数量经常超过30个以上的列，那么也应该选择行存方式。如果选择列的数量非常有限，并且希望通过较高的压缩比换取海量数据查询时的较好的IO性能，那么就应该选择列存模式。但是需要注意的是，如果是列存分区表，每个分区的每个列都会有一个对应的物理文件。比如有100个分区，100个列，那么就会产生10000个文件，默认情况下，这些文件都会放在一个目录中。这可能会导致两方面的问题，一个是访问数据时有可能超越linux上允许同时打开文件数量的上限。另一个是在同一个目录内，存放过多的文件，会导致DDL命令的效率很差。解决这两个问题，一个是尽量在SQL中使用事实表的分区键作为条件，或者尽量指定需要访问的事实表分区，以减少文件的访问。另外，应该创建不同的表空间（相当于不同的系统目录），把分区放入不同的表空间。
5. SQL优化的考虑：
explain和explain analyze是有区别的。explain是基于统计，给出执行计划，他不会真正执行SQL，因此没有执行统计。explain analyze会真正执行SQL因此会提供执行过程中真实资源消耗统计，但是对在线系统可能影响会较大。
如果是从超大结果集合中返回非常小的结果集（不超过5%），建议使用BTREE索引（非典型数据仓库操作）。表记录的存储顺序最好与索引一致，可以进一步减少IO（好的index cluster），where条件中的列用or的方式进行join，可以考虑使用索引，还有就是记录很多，键值大量重复时，比较适合使用bitmap索引。
7. 函数和存储过程的书写：
虽然支持游标但是，尽量不要使用游标方式处理数据，而是应该把数据作为一个整体进行操作。