EnterpriseDB 数据库服务器路线图

来自 PostgreSQL wiki
跳转到导航跳转到搜索

对于即将到来的 PostgreSQL 开发周期,2016-2017 年,可能的版本号为 10 或 10.0,EnterpriseDB 的数据库服务器团队打算致力于以下项目。与任何其他代码贡献一样,无法保证这项工作能够按时完成,也无法保证社区会接受它。EnterpriseDB 及其员工欢迎其他人在这些领域进行工作,并在工作重叠的情况下与其他公司或个人贡献者进行合作。我们的计划可能会根据社区反馈或公司优先事项进行调整,因此我们无法保证所有事情都将完全按照这里描述的那样进行。

(请注意,并非所有参与 PostgreSQL 开发的 EnterpriseDB 人员都是 EnterpriseDB 数据库服务器组的成员。特别是,Bruce Momjian 不是数据库服务器组的成员,他的任何开发计划都没有反映在此处。)

并行性

我们打算致力于改进 并行查询,以及添加并行实用程序命令。

  • Thomas Munro 正在开发一个基于哈希表的结构,它将键、值和元数据存储在动态共享内存段中。它还没有准备好与 PostgreSQL 社区共享,但我们打算在这个发布周期早期进行共享。它基于 Robert Haas 早期发布但从未提交的工作。我们打算使用这个动态哈希表来构建一个 **并行哈希** 节点,以便并行哈希连接可以使用共享哈希表,而不是每个工作程序使用一个单独的哈希表。
  • 我们还打算使用这个哈希表来构建一个 **并行位图堆扫描** 节点。对 TPC-H 查询计划的分析表明,这将显着提高多个 TPC-H 查询的性能。
  • Rushabh Lathia 正在开发一个 **收集合并** 节点,它类似于收集,但将排序后的元组流合并成单个排序后的元组输出流。
  • Rahila Syed 正在开发一个 **并行索引扫描** 节点,以便并行计划的驱动表可以是索引扫描,而不是顺序扫描。Rahila 的补丁的第一个版本很可能只支持 B 树索引;我们可以寻求其他索引类型专家的帮助,将其扩展到支持所有类型的索引。
  • 并行查询对子查询有严格的限制,我们希望看到这些限制得到放松。我们不确定是否有人有时间在这个发布周期内处理这个问题,但我们认为它很重要。如果其他人有时间处理,那将是极好的。如果没有,如果时间允许,我们会处理它。
  • Robert Haas 和其他人可能会帮助审查和提交任何提议添加并行实用程序命令的补丁。如果我们自己开发,最有可能的候选者是 **并行 VACUUM**。

分区

  • 一旦我们有了分区,Ashutosh Bapat 将致力于使查询规划器更智能地处理分区表。例如,如果两个 Append 节点中的表是兼容分区,则可以将它们的连接转换为连接的 Append;预计这种方式的性能会更好。类似的优化也适用于聚合。

外部数据包装器

  • 我们希望致力于为postgres_fdw添加聚合下推。这将使用 Tom Lane 在 PostgreSQL 9.6 开发周期后期添加的新规划器钩子。它将类似于在 9.5 和 9.6 开发周期中完成的连接下推工作,并将使像SELECT COUNT(*) FROM remote_table这样的查询快速运行,而不是缓慢运行。
  • 我们希望为 PostgreSQL 执行器添加对异步执行的支持。假设我们有一个继承层次结构,其中一些成员是外部表 - 或者如果我们有分区,也许一些分区是外部表。目前,我们将一次查询每个子表。最好一次查询所有子表,并返回最先返回的结果。异步执行将允许我们做到这一点。异步执行似乎也可能对并行查询等其他应用程序有用,但需要更多工作来确定它在该上下文中的确切用途。
  • 我们有兴趣看到一个可插拔的堆存储 API,作为 FDW API 的扩展或单独的东西。目前,我们没有具体的方案,但我们认为有一些重要的性能优化(只读数据、列存储、仅索引表、非事务表)只能使用专门的存储格式才能实现。此外,这将为替换现有的堆格式提供空间,这可能是某人将来想做的事情。

复制

  • Robert Haas 将帮助审查其他人可能发布的与逻辑复制相关的任何补丁。

垂直扩展

  • Mithun Cy 将继续追求缓存 MVCC 快照的补丁,以减少对ProcArrayLock的争用。(这基于 Andres Freund 的最初工作,他目前在 Citus Data 工作。)

性能

  • 我们非常有兴趣尝试重新设计执行器数据结构,以便能够对元组批次进行操作,而不是单个元组。我们认为这可以显着提高速度。我们也对其他使执行器更快的想法感兴趣,并将审查其他人发布的补丁,也可能编写其他补丁。
  • nodeSeqscan.c 中有一条注释,它说我们没有将扫描键下推到 heapam 层是非常糟糕的。Dilip Kumar 做了一些原型设计,表明我们可以通过下推扫描键来提高性能,因此我们可能会尝试在这个领域找出一些方法。

SQL 特性

  • Kevin Grittner 仍然计划继续他的补丁,以添加OLDNEW元组存储到AFTER STATEMENT触发器中,这些触发器请求它们。这被认为是朝着增量更新的物化视图发展基础设施的方向迈出的一步。
  • 我们可能会开发一些补丁,以在 PostgreSQL 9.6 中添加的事件之上添加额外的等待事件,并将帮助审查其他人发布的此类补丁。我们认为,对于 PostgreSQL 来说,改进这个系统以涵盖基本上所有可能产生重大等待的情况,将是件好事。