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