#1 楼
否,适用于v9.6之前的PostgreSQL版本。请参阅PostgreSQL常见问题解答:PostgreSQL如何使用CPU资源?PostgreSQL服务器是基于进程的(非线程)。每个数据库会话都连接到单个PostgreSQL操作系统(OS)进程。操作系统会自动将多个会话分布在所有可用的CPU上。该操作系统还使用CPU处理磁盘I / O并运行其他非数据库任务。客户端应用程序可以使用线程,每个线程都连接到单独的数据库进程。
从9.6版开始,某些查询的某些部分可以在单独的OS进程中并行运行,从而允许使用多个CPU内核。默认情况下,版本10(max_parallel_workers_per_gather)中启用了并行查询,并且在将来的发行版中还期望其他并行性。
#2 楼
从PostgreSQL 9.6起,将开始看到Parallel-Query最终进入PostgreSQL。例如诸如并行扫描/并行联接/并行聚合之类的概念现在已经开始普及,即将推出更多。
真正令人兴奋的是,有报道证实在某些情况下
near-linear speed-up
,这非常令人印象深刻! br />#3 楼
否,但是有一种解决方法。 :)我发现了parsel(并行选择)plpgsql函数,该函数基于主键拆分查询,然后通过dblink扩展连接到数据库并等待所有子查询。
https://gist.github.com/mjgleaso/8031067
作者还撰写了有关此功能的文章:http://geeohspatial.blogspot.com/2013/12/a-simple-function- for-parallel-queries_18.html
#4 楼
否。每个连接都会在服务器上生成一个单独的进程。您可以使用线程化程序语言(如pljava)“模拟”一些并行性。
创建一个Java过程(函数)来启动多个线程并使用多个工作器创建输出结果。
后端被同步化,因此每个工作器都可以异步更新输出。
Java对线程协调/协作具有良好的支持。
例如,这将非常适合CPU密集型操作或网络长度操作。
评论
Cant相信在这个现代时代,设计将倾向于使用重载过程上下文切换来实现多任务,而不是使用轻量级高性能多线程。谢谢你的澄清。这就解释了为什么当我们根据一些显然不好的建议切换到Postgres时,我们的系统现在承受负载的原因。
– Bill
20 Mar 31 '20在15:48