Gre*_*der 6 sql database postgresql performance
我知道多个连接在 postgres 中使用多个 CPU 核心，因此并行运行。但是当我执行一个长时间运行的查询（比如 30 秒）（假设这不能进一步优化）时，I/O 被阻塞，并且它不会从同一客户端/连接运行任何其他查询。
这是设计使然还是可以改进？
因此，我假设运行长时间运行的查询的最佳方法是获取新连接，或者在该查询完成之前不在同一连接中运行任何其他查询？
这是一个设计限制。
PostgreSQL 每个连接使用一个进程，并且每个进程有一个会话。每个进程都是单线程的，并大量使用fork()从 postmaster 继承的全局变量。共享内存是显式管理的。
这在易于开发、调试和维护方面具有一些很大的优势，并使系统在面对错误时更加健壮。但是，这使得在查询级别添加并行化变得更加困难。
添加并行查询支持的工作正在进行中，但目前该系统实际上仅限于每个查询使用一个 CPU 核心。它可以从某些领域的并行 I/O 中受益，例如位图索引扫描（通过effective_io_concurrency），但在其他领域则不然。
在我看来，有一些非常棘手的解决方法，例如PL/Proxy，但大多数情况下，如果需要的话，您必须在客户端自己处理并行化。这正迅速成为影响 PostgreSQL 的更重要的限制之一。应用程序可以将大型查询拆分为多个影响数据子集的较小查询，然后统一客户端（或统一到未记录的表中，然后进一步处理），即映射/减少样式模式。如果需要混合使用大型长时间运行查询和低延迟 OLTP 查询，则需要多个连接，并且应用程序通常应使用内部连接池。