Greenplum函数编程心得

声明：文中观点为作者的个人观点、不代表官方、如需更多帮助，请联系Pivotal官方·转载必须注明出处
1、Greenplum函数中的预编译SQL无法识别分区条件，遭遇该问题的用户极为普遍，而EMC通常给出的意见是采用EXECUTE执行动态拼凑的SQL语句。
   如果你已经这么干了，我可以体会你那种想骂娘的痛苦，因为在GP的Function中去拼凑SQL是很不人性化的方法，所有的单引号都需要被转义，所有
   的变量都需要用【||】这玩意去拼接，想要清晰直观的看明白逻辑，想要修改业务逻辑，想要修改BUG，那绝对是痛不欲生。作者告诉你，其实可以
   尝试考虑一下sql或者plpgsql之外的language，在这两种亲生的数据库language范围内，是无法避免动态拼接的，除非你接受全表扫描的分区查询。
   作者要推荐的是PLPERL，至于PLPERLU这里不去讨论二者的差异，在PERL中，有一种字符串表达方法：qq，就是英文两个引号的缩写，其允许直接书写
   字符串原文，允许有变量替换。在PERL中，编程的灵活性对于SQL来说也有极大的提升。
   至于使用PLPERL作为language来编写GP Function的更多细节，请参考相关手册。
2、关于PLPERL和Plpythonu中的全局字典表，从PG中文手册上看，PLPERL是会话级别的共享，而从英文资料上看，Plpythonu也是会话级别的共享，于是，
   如果你想要刷新全局字典中缓存的内容，那就有麻烦了，因为在这两种语言内部执行SQL都是跳出会话执行的。但后来作者发现，Plpythonu可以通过
   重建Function来达到清除字典缓存的目的。
3、PERL中有指针，Python中无指针，而且，Python中的赋值操作是深度复制，所以，前文【范围关联】算法探讨 中提到的Python实现与C之间的50倍性能
   差异是不合理的，虽然两者实现的是相同的算法，测试相同的数据，但Python走的是深度复制策略，性能直接打了很大的折扣。发现这一现象也是一个
   偶然的机会，还是在某快递公司开发的时候发现，最初写好的PERL函数，在half DCA1.0环境，每秒只能处理1万左右的数据，这个性能让我一个周末都在
   苦苦思索，为什么会这么慢，平均一颗CPU每秒才处理200条数据，慢到我无法接受。那个周末我的思考是凭空的，因为我没有看代码，完全靠感觉去思考，
   最终我意识到，也许在PERL中直接使用指针来获取全局字典中的对象会带来性能提升，在我的函数中有3个被缓存到全局字典中的数据，记录数达到一两万，
   周一我做的第一件事，就是把对象复制改为指针，意想不到的效果出现了，性能提升了100倍左右。
4、在写Function时使用PLPERL或者Plpythonu作为Language还可以绕开表未定义的BUG。方法就是，将创建表的语句单独执行即可，此法不会带来很多麻烦。
   但却可以确保Function中的业务实现如同在pgadmin中那样灵活多变。
注，要在GP中使用Python或者PERL来开发函数势必带来一些额外的学习压力，但你得到的远大于付出。
 要获得高效的解决方案，关键不是花了多少时间去编码，关键是花了多少心思去思考，思考每个你认为不满意或不完美的点
 个人建议使用PLPERL编写业务函数
声明：文中观点为作者的个人观点、不代表官方、如需更多帮助，请联系Pivotal官方·转载必须注明出处

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/11022757/viewspace-1242320/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/11022757/viewspace-1242320/