在 Postgres 中查询单个连接的并行化答案

【问题标题】：Query parallelization for single connection in Postgres在 Postgres 中查询单个连接的并行化
【发布时间】：2015-09-17 12:09:05
【问题描述】：

我知道多个连接在 postgres 中使用多个 CPU 内核，因此并行运行。但是当我执行一个长时间运行的查询时说 30 秒（假设这无法进一步优化），I/O 被阻塞并且它不会从同一客户端/连接运行任何其他查询。

这是设计使然还是可以改进？

所以我假设运行长时间运行的查询的最佳方法是获取新连接，或者在该查询完成之前不在同一连接中运行任何其他查询？

【问题讨论】：

这是设计使然，不能（当前）更改。如果您想并行工作，您将需要打开第二个连接。即使 Postgres 能够在后端使用多个核心进行单个查询 - 启动该查询的连接仍然会被阻止。
我想这可能会回答你的问题：stackoverflow.com/questions/11620263/…
这并没有完全回答我的问题，但提供了更多的见解，谢谢。 @a_horse_with_no_name ：我的假设在这里是否正确，如果它是一个长时间运行的查询，如果连接便宜，请在新连接上运行它/不要在同一连接中运行任何需要快速周转的查询？
在您编辑后发表评论。现在有意义了。谢谢 :)

标签： sql database performance postgresql

【解决方案1】：

这是一个设计限制。

PostgreSQL 每个连接使用一个进程，每个进程有一个会话。每个进程都是单线程的，并且大量使用通过fork() 从邮局管理员继承的全局变量。共享内存是显式管理的。

这在易于开发、调试和维护方面有一些很大的优势，并使系统在面对错误时更加健壮。但是，这使得在查询级别添加并行化变得更加困难。

正在进行添加并行查询支持的工作，但目前系统实际上仅限于每个查询使用一个 CPU 内核。它可以在某些领域受益于并行 I/O，例如位图索引扫描（通过effective_io_concurrency），但在其他领域则不行。

有一些 IMO 非常老套的解决方法，例如 PL/Proxy，但如果需要，大多数情况下您必须自己在客户端处理并行化。这正迅速成为影响 PostgreSQL 的更重要的限制之一。应用程序可以将大型查询拆分为多个影响数据子集的较小查询，然后统一客户端（或统一到未记录的表中，然后进一步处理），即 map/reduce 样式模式。如果需要混合大量长时间运行的查询和低延迟的 OLTP 查询，则需要多个连接，并且应用通常应使用内部连接池。

【讨论】：

...如果您要实现手动并行，您可能会发现对主表进行分区很有帮助（当然，所有关于分区的常见警告仍然适用）。