materialize

PostgreSQL的并行化包含三个重要组件：进程本身(leader进程)、gather、workers。没有开启并行化的时候，进程自身处理所有的数据；一旦计划器决定某个查询或查询中部分可以使用并行的时候，就会在查询的并行化部分添加一个gather节点，将gather节点作为子查询树的根节点。 查询执行是从leader进程开始。一旦开启了并行或查询中部分支持并行，就会分配一个gather节点和多个worker线程。relation的blocks在各个workers线程之间划分。workers的数量受postgresql的配置参数控制。workers之间使用共享内存相互协调和通信，一旦worker完成了自己的工作，结果就被传给了leader进程。 workers和leader进程之间使用消息队列(依赖共享内存)进行通信。每个进程有两个队列：一个是error队列；一个是tuples队列。 并行顺序扫描(Parallel sequential scan) 在PostgreSQL 9.6中，增加了对并行顺序扫描的支持。顺序扫描是在表上进行的扫描，在该表中一个接一个的块顺序地被评估。就其本质而言，顺序扫描允许并行化。这样，整个表将在多个workers线程之间顺序扫描。 并行顺序扫描快并不是因为可以并行地读，而是将数据分散到了多个cpu。 abce=# explain analyze

作者：胡呈清 爱可生 DBA 团队成员，擅长故障分析、性能优化，个人博客： https://www.jianshu.com/u/a95ec11f67a8，欢迎讨论。 本文来源：原创投稿 *爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。 有这么一个 SQL，外查询 where 子句的 bizCustomerIncoming_id 字段，和子查询 where 字句的 cid 字段都有高效索引，为什么这个 SQL 执行的非常慢，需要全表扫描？ delete FROM biz_customer_incoming_path WHERE bizCustomerIncoming_id IN \ (SELECT id FROM biz_customer_incoming WHERE cid='315upfdv34umngfrxxxxxx'); 我们从这么一个问题来引入接下来的内容，如果你知道答案就不用继续看下去了。 子查询优化策略 对于不同类型的子查询，优化器会选择不同的策略。 对于 IN、=ANY 子查询，优化器有如下策略选择： semijoin Materialization exists 对于 NOT IN、<>ALL 子查询，优化器有如下策略选择： Materialization exists 对于 derived 派生表，优化器有如下策略选择：