加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 百科 > 正文

Postgresql version 9.0 和之前版本的一个BUG

发布时间:2020-12-13 17:50:21 所属栏目:百科 来源:网络整理
导读:最近,由于性能的问题把一些大数据量的表改为分区表(partition table)。在postgresql下这个过程也是很艰难的,参见我的另一篇文章。 本来这是一件利国利民的好事,谁料居然发生了没有料想到的事情。几天后有人发现对某个分区表的一个查询特别的慢。查看后

最近,由于性能的问题把一些大数据量的表改为分区表(partition table)。在postgresql下这个过程也是很艰难的,参见我的另一篇文章。

本来这是一件利国利民的好事,谁料居然发生了没有料想到的事情。几天后有人发现对某个分区表的一个查询特别的慢。查看后发现数据量大概为500w-600w查询时间居然需要12s-13s。 这个不正常,分析后发现该sql中单单一个 select max(time_stamp) from **table; 的语句基本就耗费了11-12s。吼吼,这就更不正常了。查看查询分析的结果发现在所有分区的查询都是全表扫描(full table scan)。这不应该啊,因为字段time_stamp是联合主键之一啊怎么也应该是索引扫描啊(index scan),看来这就是查询性能低下的原因了。略过长时间的分析,未果。没辙了只好去postgrsql的maillist找答案,唉,果然给找到了,我擦。http://archives.postgresql.org/pgsql-performance/2011-02/msg00234.php

原来这是postgrsql的一个bug,存在于9.0**和之前的版本中,我们正好使用的是9.0版本。唉。速度下载version9.1并试验同一个sql。耗时4-5ms,查看查询分析,都是索引扫描。 总结:使用不成熟的产品需谨慎啊,好在9.1.*已经在今年4月份release了,我们可以通过升级版本解决这个问题,要是没有release我们怎么办呢?

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读