2024 Postgres Conference 大会丨一文详解拓数派干货演讲精华内容
4月17日-19日,全球规模最大的 PostgreSQL 会议之一——Postgres Conference 2024 在美国 San Jose 隆重举行,本届大会包含 Ops、Dev、Essentials 和 Google Cloud 四个 Track,话题围绕 PostgreSQL 内核、数据库管理与应用、用户实例与经验等主题展开,邀请了来自谷歌、AWS、EDB、Yugabyte、DBeaver 等企业的资深讲师出席大会。拓数派凭借其强大的国际技术社区影响力,受邀作为会议赞助商参与本次盛会,并发表技术演讲。
在大会中,PieCloudDB 技术专家 Richard Guo 作为新 PostgreSQL Contributor,受邀发表技术演讲《A high-level introduction to the query planner in PostgreSQL》,结合 PieCloudDB Database 优化器打造经验,从开发者的角度阐述 PostgreSQL 优化器的工作原理,并详细介绍查询树转换为计划树的过程。Richard 的演讲得到了参会观众的积极反馈,并进行了深入的互动和沟通。
数据库管理系统(DBMS)中,SQL 查询处理是一个复杂且关键的过程。对于 PostgreSQL,一条 SQL 语句从接收到执行一共需要经过下面五个主要步骤:
- 解析(Parser): 负责检查语法错误并生成解析树(parser tree);
- 分析(Analyzer): 根据解析树进行语义分析,生成一棵查询树(query tree);
- 重写(Rewriter): 按照系统存在的规则对查询树进行重写;
- 规划/优化(Planner): 基于查询树生成一棵执行效率最高的计划树(plan tree);
- 执行(Executor): 按照计划树中的顺序访问表和索引,执行相应查询。
对于同一个查询语句,一般可以由多种方式去执行,查询优化器作为数据库的重要组件,它的作用就是从每一种可能的执行方式中,找到代价最小的查询计划,并把它转换成可执行的计划树。
下面将着重介绍 PostgreSQL 查询处理过程中的规划/优化阶段,这也是整个流程中最重要以及最复杂的阶段。该过程一般被分为四个阶段:预处理阶段,扫描/连接优化阶段,扫描/连接之外的优化阶段以及后处理阶段。
1. 预处理阶段
在预处理阶段的早期一般会通过简化常量表达式(函数、布尔、CASE 等)、内联简单的 SQL 函数等方式,尽可能的简化查询。同时,还会通过把 IN, EXISTS 等类型的子查询转换为半连接、提升子查询以及把消除外连接(将其转换为内连接或反连接)等操作来简化连接树。
除了这些方法,在预处理阶段的后期还会采用多种优化方式,包括:
- 分发 WHERE 和 JOIN/ON 约束条件
- 构建等价类
- 收集关于连接顺序限制的信息
- 消除无用连接
- ...
2. 扫描/连接优化阶段
扫描/连接优化阶段主要处理查询语句中 FROM 和 WHERE 部分,同时也会考虑 ORDER BY 的信息。这一部分都是由代价来驱动的。
该阶段首先为基表确定扫描路径,估计扫描路径的代价,然后利用动态规划和遗传算法,搜索整个连接顺序空间,生成连接路径。而在搜索连接顺序空间时,还需要考虑到由外连接带来的连接顺序的限制。
在动态规划中,连接搜索会按照如下的过程进行:
- 首先为每一个基表生成扫描路径
- 为所有可能的两个表的连接生成连接路径
- 为所有可能的三个表的连接生成连接路径
- 为所有可能的四个表的连接生成连接路径
- ...
- 直到所有基表都连接在了一起
然而这个过程的代价是非常高的,n 个表的连接,理论上有 n! 个不同的连接顺序,遍历所有可能的连接顺序是不现实的。因此通常会使用一些启发式办法,减少搜索空间,对于不存在连接条件的表,尽量不做连接;把一个大的问题,分解成多个子问题,从而降低复杂度。
3. 扫描/连接之外的优化阶段
在该阶段优化器会优先处理 GROUP BY、聚集、窗口函数和 DISTINCT,再对集合(UNION/INTERSECT/EXCEPT)操作进行处理,最后再处理 ORDER BY。以上的每个步骤都会产生一个或多个路径,优化器会对这些路径基于代价进行筛选,并为筛选出的路径添加 LockRows,Limit 和 ModifyTable 节点。
4. 后处理阶段
在这一阶段,优化器需要把代价最小的路径转换成计划树,并且调整计划树中的一些细节:
- 展平子查询的范围表
- 把上层计划节点中的变量变成 OUTER_VAR 或 INNER_VAR 的形式,来指向子计划的输出
- 删除不必要的 SubqueryScan、Append、MergeAppend 等节点
做完这一步,优化器就得到了完整的计划树,并可以将该计划树交予执行器去执行,最终得到查询结果。
作为立足中国的高科技创新企业,拓数派近年来通过代码贡献、讲师布道、会议赞助与参与、生态合作等多种形式,深耕于国际开源技术与生态体系。未来,拓数派将不断拓宽国际视野,积极融入全球科技创新的浪潮,扩大国际影响力,打造为国际化的技术驱动型企业。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
开源日报 | “鸿蒙原生版”微信;小镇里的“大模型”;全网最刚游戏公司;半个AI圈向李彦宏「开炮」
欢迎阅读 OSCHINA 编辑部出品的开源日报,每天更新一期。 # 2024.4.25 今日要点 nginx 1.26.0 稳定版实验性支持 HTTP/3 主要变化 合并来自 1.25.x 主线分支的新功能和错误修复 实验性支持 HTTP/3 流模块 (stream module) 引入虚拟服务器 支持将流连接传递给监听套接字 HTTP/2 on aper-serverbasis 下载地址 苹果开源面向移动设备打造的小尺寸模型 OpenELM 苹果在 Hugging Face 平台上发布了一个「具有开源训练和推理框架的高效语言模型」,名为 OpenELM。OpenELM 使用分层缩放策略,可以有效地分配 Transformer 模型每一层的参数,从而提高准确率。例如,在参数量约为 10 亿的情况下,OpenELM 与 OLMo 相比准确率提升了 2.36%,同时所需的预训练 tokens 数量仅有原来的 50%。 OpenELM 有四种尺寸:2.7 亿、4.5 亿、11 亿和 30 亿个参数。而微软 Phi-3 模型为 38 亿,因此前者在小型机型上运行成本更低,可在手机和笔记本电脑等...
- 下一篇
你唯一需要的是“Wide Events”,而非“Metrics、Logs、Traces”
Charity Majors 的这句话可能是对科技行业当前可观察性状态的最好总结——完全的、大规模的混乱。大家都很困惑。什么是 trace?什么是 span?一行日志就是一个 span 吗?如果我有日志,我还需要 trace 吗?如果我有很好的 metric,为什么还需要 trace?诸如此类的问题不胜枚举。Charity 与Honeycomb可观测系统中的其他杰出人士一起,一直在努力解决这些问题。然而,根据我自己的经验,仍然很难解释 Charity 所说的“日志是垃圾”是什么意思,更不用说日志和跟踪本质上是同一件事了。为什么大家都这么困惑呢? 冒一点风险,我要怪罪 Open Telemetry。是的,它是现代可观测性技术栈的动力源泉,然而我却将混乱的局面归咎于它。这并不是因为它是一个糟糕的解决方案 - 它非常出色!但是它本身的介绍、对 Open Telemetry 的概念和功能的讲解,都使得可观测性看起来棘手而复杂。 首先,Open Telemetry 从一开始就明确区分了跟踪、指标和日志: OpenTelemetry is a collection of APIs, SDKs, a...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- 设置Eclipse缩进为4个空格,增强代码规范
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- CentOS7,8上快速安装Gitea,搭建Git服务器
- SpringBoot2整合Redis,开启缓存,提高访问速度
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- CentOS6,CentOS7官方镜像安装Oracle11G
- MySQL8.0.19开启GTID主从同步CentOS8
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- Red5直播服务器,属于Java语言的直播服务器
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装