开发者社区> 德哥> 正文

PostgreSQL 10.0 preview sharding增强 - pushdown 增强

简介:
+关注继续查看

标签

PostgreSQL , 10.0 , sharding , pushdown , postgres_fdw


背景

PostgreSQL 10.0 已经可以看到的sharding增强如下:

1. Push down more full joins in postgres_fdw

full join下推

2. Push down more UPDATEs/DELETEs in postgres_fdw

update/delete下推

3. PassDownLimitBound for ForeignScan/CustomScan

limit限制下推

加之前面已有的where,select clause,join,聚合,函数下推,大多数常见运算都可以下推了。

结合postgres_fdw的异步调用,继承与分区表,sharding已经非常的完善,就差分布式事务了,10.0的postgres_fdw也在支持2pc,未来PostgreSQL内置sharding会非常顺溜。


后续还会持续看到更多的增强

这个patch的讨论,详见邮件组,本文末尾URL。

PostgreSQL社区的作风非常严谨,一个patch可能在邮件组中讨论几个月甚至几年,根据大家的意见反复的修正,patch合并到master已经非常成熟,所以PostgreSQL的稳定性也是远近闻名的。

参考

https://commitfest.postgresql.org/13/727/

https://commitfest.postgresql.org/13/791/

https://commitfest.postgresql.org/13/1064/

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
PostgreSQL 12 preview - 可靠性提升 - data_sync_retry 消除os层write back failed status不可靠的问题
标签 PostgreSQL , data_sync_retry , write back , retry , failed status 背景 有些OS系统,对fsync的二次调用不敏感,因为OS层可能有自己的CACHE,如果使用了buffer write,并且出现write back failed的情况,有些OS可能在下次fsync时并不能正确的反馈fsync的可靠性与否。(因为这个B
421 0
PostgreSQL 12 preview - CTE 增强,支持用户语法层控制 materialized 优化
标签 PostgreSQL , CTE , materialized , not materialized , push down 背景 PostgreSQL with 语法,能跑非常复杂的SQL逻辑,包括递归,多语句物化计算等。 在12以前的版本中,WITH中的每一个CTE(common table express),都是直接进行物化的,也就是说外层的条件不会推到CTE(物化节点)里
628 0
PostgreSQL sharding : citus 系列7 - topn 加速(count(*) group by order by count(*) desc limit x) (use 估值插件 topn)
标签 PostgreSQL , topn , topn.number_of_counters , count(*) group by order by count(*) desc limit x 背景 count(*) group by order by count(*) desc limit x 用来统计 topn。
1222 0
PostgreSQL sharding : citus 系列6 - count(distinct xx) 加速 (use 估值插件 hll|hyperloglog)
标签 PostgreSQL , hll , hyperloglog , distinct , 加速 , citus.count_distinct_error_rate 背景 在分布式数据库中,计算count(distinct xxx),需要对distinct 的字段, 1、去重, 2、重分布去重后的数据,(这一步,如果distinct值特别多,那么就会比较耗时) 3、然后再去重, 4、最后count (xxx), 5、求所有节点的count SUM。
1678 0
PostgreSQL sharding : citus 系列5 - worker节点网络优化
标签 PostgreSQL , citus , pgbouncer , 网络优化 , worker节点 背景 citus 节点间的网络需求: 1、cn节点访问所有worker节点。oltp业务的访问较频繁。
1286 0
PostgreSQL sharding : citus 系列4 - DDL 操作规范 (新增DB,TABLE,SCHEMA,UDF,OP,用户等)
标签 PostgreSQL , citus , 新增对象 , 新增数据库 , 新增用户 背景 citus是PG的一个插件,插件主要针对普通SQL(非UTILITY)加HOOK进行了一些ROUTE处理,同时使用UDF对表进行新建分区的操作。
1507 0
PostgreSQL sharding : citus 系列3 - 窗口函数调用限制 与 破解之法(套用gpdb执行树,分步执行)
标签 PostgreSQL , citus , 窗口函数 背景 窗口函数是分析场景常用的,目前(citus 7.5)仅支持两种场景使用window函数, 1、partition by 必须是分布键。
1252 0
PostgreSQL sharding : citus 系列2 - TPC-H
标签 PostgreSQL , citus , tpc-h 背景 紧接着上一篇文档,本文测试citus的tpc-h能力(包括兼容性). 《PostgreSQL sharding : citus 系列1 - 多机部署(含OLTP(TPC-B)测试)》 《(TPC-H测试 SF=10,SF=200) PostgreSQL 11 vs 10 vs Deepgreen》 https://github.com/digoal/gp_tpch 实际测试过程中,发现CITUS对TPC-H的SQL支持并不完整。
1893 0
PostgreSQL sharding : citus 系列1 - 多机部署(含OLTP(TPC-B)测试)- 含Citus MX模式
标签 PostgreSQL , citus , tpc-b , cn mx 背景 《(TPC-H测试 SF=10) PostgreSQL 11 vs 10 vs Deepgreen》 测试结果证明PG已经是一个HTAP数据库,可以同时满足OLTP,OLAP的需求。
2499 0
+关注
德哥
公益是一辈子的事, I am digoal, just do it.
文章
问答
视频
文章排行榜
最热
最新
相关电子书
更多
PostgreSQL 物联网六脉神剑
立即下载
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载
相关镜像