脚本之家 服务器常用软件
快捷导航
您的位置：首页 → 数据库 → PostgreSQL → postgresql insert into select并行查询

postgresql insert into select无法使用并行查询的解决

 更新时间：2021年01月08日 10:40:23   作者：瀚高PG实验室  
这篇文章主要介绍了postgresql insert into select无法使用并行查询的解决，文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值，需要的朋友们下面随着小编来一起学习学习吧

本文信息基于PG13.1。

从PG9.6开始支持并行查询。PG11开始支持CREATE TABLE … AS、SELECT INTO以及CREATE MATERIALIZED VIEW的并行查询。

先说结论：

换用create table as 或者select into或者导入导出。

首先跟踪如下查询语句的执行计划：

select count(*) from test t1,test1 t2 where t1.id = t2.id ;

postgres=# explain analyze select count(*) from test t1,test1 t2 where t1.id = t2.id ;
                                    QUERY PLAN                                    
--------------------------------------------------------------------------------------------------------------------------------------------------------
 Finalize Aggregate (cost=34244.16..34244.17 rows=1 width=8) (actual time=683.246..715.324 rows=1 loops=1)
  -> Gather (cost=34243.95..34244.16 rows=2 width=8) (actual time=681.474..715.311 rows=3 loops=1)
     Workers Planned: 2
     Workers Launched: 2
     -> Partial Aggregate (cost=33243.95..33243.96 rows=1 width=8) (actual time=674.689..675.285 rows=1 loops=3)
        -> Parallel Hash Join (cost=15428.00..32202.28 rows=416667 width=0) (actual time=447.799..645.689 rows=333333 loops=3)
           Hash Cond: (t1.id = t2.id)
           -> Parallel Seq Scan on test t1 (cost=0.00..8591.67 rows=416667 width=4) (actual time=0.025..74.010 rows=333333 loops=3)
           -> Parallel Hash (cost=8591.67..8591.67 rows=416667 width=4) (actual time=260.052..260.053 rows=333333 loops=3)
              Buckets: 131072 Batches: 16 Memory Usage: 3520kB
              -> Parallel Seq Scan on test1 t2 (cost=0.00..8591.67 rows=416667 width=4) (actual time=0.032..104.804 rows=333333 loops=3)
 Planning Time: 0.420 ms
 Execution Time: 715.447 ms
(13 rows)

可以看到走了两个Workers。

下边看一下insert into select：

postgres=# explain analyze insert into va select count(*) from test t1,test1 t2 where t1.id = t2.id ;     
                                  QUERY PLAN                                  
--------------------------------------------------------------------------------------------------------------------------------------------------
 Insert on va (cost=73228.00..73228.02 rows=1 width=4) (actual time=3744.179..3744.187 rows=0 loops=1)
  -> Subquery Scan on "*SELECT*" (cost=73228.00..73228.02 rows=1 width=4) (actual time=3743.343..3743.352 rows=1 loops=1)
     -> Aggregate (cost=73228.00..73228.01 rows=1 width=8) (actual time=3743.247..3743.254 rows=1 loops=1)
        -> Hash Join (cost=30832.00..70728.00 rows=1000000 width=0) (actual time=1092.295..3511.301 rows=1000000 loops=1)
           Hash Cond: (t1.id = t2.id)
           -> Seq Scan on test t1 (cost=0.00..14425.00 rows=1000000 width=4) (actual time=0.030..421.537 rows=1000000 loops=1)
           -> Hash (cost=14425.00..14425.00 rows=1000000 width=4) (actual time=1090.078..1090.081 rows=1000000 loops=1)
              Buckets: 131072 Batches: 16 Memory Usage: 3227kB
              -> Seq Scan on test1 t2 (cost=0.00..14425.00 rows=1000000 width=4) (actual time=0.021..422.768 rows=1000000 loops=1)
 Planning Time: 0.511 ms
 Execution Time: 3745.633 ms
(11 rows)

可以看到并没有Workers的指示，没有启用并行查询。

即使开启强制并行，也无法走并行查询。

postgres=# set force_parallel_mode =on;
SET
postgres=# explain analyze insert into va select count(*) from test t1,test1 t2 where t1.id = t2.id ;
                                  QUERY PLAN                                  
--------------------------------------------------------------------------------------------------------------------------------------------------
 Insert on va (cost=73228.00..73228.02 rows=1 width=4) (actual time=3825.042..3825.049 rows=0 loops=1)
  -> Subquery Scan on "*SELECT*" (cost=73228.00..73228.02 rows=1 width=4) (actual time=3824.976..3824.984 rows=1 loops=1)
     -> Aggregate (cost=73228.00..73228.01 rows=1 width=8) (actual time=3824.972..3824.978 rows=1 loops=1)
        -> Hash Join (cost=30832.00..70728.00 rows=1000000 width=0) (actual time=1073.587..3599.402 rows=1000000 loops=1)
           Hash Cond: (t1.id = t2.id)
           -> Seq Scan on test t1 (cost=0.00..14425.00 rows=1000000 width=4) (actual time=0.034..414.965 rows=1000000 loops=1)
           -> Hash (cost=14425.00..14425.00 rows=1000000 width=4) (actual time=1072.441..1072.443 rows=1000000 loops=1)
              Buckets: 131072 Batches: 16 Memory Usage: 3227kB
              -> Seq Scan on test1 t2 (cost=0.00..14425.00 rows=1000000 width=4) (actual time=0.022..400.624 rows=1000000 loops=1)
 Planning Time: 0.577 ms
 Execution Time: 3825.923 ms
(11 rows)

原因在官方文档有写：

The query writes any data or locks any database rows. If a query contains a data-modifying operation either at the top level or within a CTE, no parallel plans for that query will be generated. As an exception, the commands CREATE TABLE … AS, SELECT INTO, and CREATE MATERIALIZED VIEW which create a new table and populate it can use a parallel plan.

解决方案有如下三种：

1.select into

postgres=# explain analyze select count(*) into vaa from test t1,test1 t2 where t1.id = t2.id ;
                                    QUERY PLAN                                    
--------------------------------------------------------------------------------------------------------------------------------------------------------
 Finalize Aggregate (cost=34244.16..34244.17 rows=1 width=8) (actual time=742.736..774.923 rows=1 loops=1)
  -> Gather (cost=34243.95..34244.16 rows=2 width=8) (actual time=740.223..774.907 rows=3 loops=1)
     Workers Planned: 2
     Workers Launched: 2
     -> Partial Aggregate (cost=33243.95..33243.96 rows=1 width=8) (actual time=731.408..731.413 rows=1 loops=3)
        -> Parallel Hash Join (cost=15428.00..32202.28 rows=416667 width=0) (actual time=489.880..700.830 rows=333333 loops=3)
           Hash Cond: (t1.id = t2.id)
           -> Parallel Seq Scan on test t1 (cost=0.00..8591.67 rows=416667 width=4) (actual time=0.033..87.479 rows=333333 loops=3)
           -> Parallel Hash (cost=8591.67..8591.67 rows=416667 width=4) (actual time=266.839..266.840 rows=333333 loops=3)
              Buckets: 131072 Batches: 16 Memory Usage: 3520kB
              -> Parallel Seq Scan on test1 t2 (cost=0.00..8591.67 rows=416667 width=4) (actual time=0.058..106.874 rows=333333 loops=3)
 Planning Time: 0.319 ms
 Execution Time: 783.300 ms
(13 rows)

2.create table as

postgres=# explain analyze create table vb as select count(*) from test t1,test1 t2 where t1.id = t2.id ;
                                   QUERY PLAN                                    
-------------------------------------------------------------------------------------------------------------------------------------------------------
 Finalize Aggregate (cost=34244.16..34244.17 rows=1 width=8) (actual time=540.120..563.733 rows=1 loops=1)
  -> Gather (cost=34243.95..34244.16 rows=2 width=8) (actual time=537.982..563.720 rows=3 loops=1)
     Workers Planned: 2
     Workers Launched: 2
     -> Partial Aggregate (cost=33243.95..33243.96 rows=1 width=8) (actual time=526.602..527.136 rows=1 loops=3)
        -> Parallel Hash Join (cost=15428.00..32202.28 rows=416667 width=0) (actual time=334.532..502.793 rows=333333 loops=3)
           Hash Cond: (t1.id = t2.id)
           -> Parallel Seq Scan on test t1 (cost=0.00..8591.67 rows=416667 width=4) (actual time=0.018..57.819 rows=333333 loops=3)
           -> Parallel Hash (cost=8591.67..8591.67 rows=416667 width=4) (actual time=189.502..189.503 rows=333333 loops=3)
              Buckets: 131072 Batches: 16 Memory Usage: 3520kB
              -> Parallel Seq Scan on test1 t2 (cost=0.00..8591.67 rows=416667 width=4) (actual time=0.023..77.786 rows=333333 loops=3)
 Planning Time: 0.189 ms
 Execution Time: 565.448 ms
(13 rows)

3.或者通过导入导出的方式，例如：

psql -h localhost -d postgres -U postgres -c "select count(*) from test t1,test1 t2 where t1.id = t2.id " -o result.csv -A -t -F ","
psql -h localhost -d postgres -U postgres -c "COPY va FROM 'result.csv' WITH (FORMAT CSV, DELIMITER ',', HEADER FALSE, ENCODING 'windows-1252')"

一些场景下也会比非并行快。

到此这篇关于postgresql insert into select无法使用并行查询的解决的文章就介绍到这了,更多相关postgresql insert into select并行查询内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

您可能感兴趣的文章:

相关文章

  • PostgreSQL中date_trunc函数的语法及一些示例

    PostgreSQL中date_trunc函数的语法及一些示例

    这篇文章主要给大家介绍了关于PostgreSQL中date_trunc函数的语法及一些示例的相关资料,DATE_TRUNC函数是PostgreSQL数据库中用于截断日期部分的函数,文中通过代码介绍的非常详细,需要的朋友可以参考下
    2024-04-04
  • 如何查看postgres数据库端口

    如何查看postgres数据库端口

    这篇文章主要介绍了如何查看postgres数据库端口操作，具有很好的参考价值，希望对大家有所帮助。一起跟随小编过来看看吧
    2021-01-01
  • 详解PostgreSQL 语法中关键字的添加

    详解PostgreSQL 语法中关键字的添加

    这篇文章主要介绍了详解PostgreSQL 语法中关键字的添加的相关资料,这里说明下在parser语法解析模块添加关键字，需要的朋友可以参考下
    2017-08-08
  • PostgreSQL怎么创建分区表详解

    PostgreSQL怎么创建分区表详解

    数据库表分区把一个大的物理表分成若干个小的物理表,并使得这些小物理表在逻辑上可以被当成一张表来使用,下面这篇文章主要给大家介绍了关于PostgreSQL怎么创建分区表的相关资料,需要的朋友可以参考下
    2022-06-06
  • PostgreSQL实战之启动恢复读取checkpoint记录失败的条件详解

    PostgreSQL实战之启动恢复读取checkpoint记录失败的条件详解

    这篇文章主要给大家介绍了关于PostgreSQL实战之启动恢复读取checkpoint记录失败的条件的相关资料，文中通过示例代码介绍的非常详细，需要的朋友可以参考借鉴，下面随着小编来一起学习学习吧
    2018-08-08
  • PostgreSQL之分区表(partitioning)

    PostgreSQL之分区表(partitioning)

    通过合理的设计，可以将选择一定的规则，将大表切分多个不重不漏的子表，这就是传说中的partitioning。比如，我们可以按时间切分，每天一张子表，比如我们可以按照某其他字段分割，总之了就是化整为零，提高查询的效能
    2016-11-11
  • Postgresql 存储过程(plpgsql)两层for循环的操作

    Postgresql 存储过程(plpgsql)两层for循环的操作

    这篇文章主要介绍了Postgresql 存储过程(plpgsql)两层for循环的操作，具有很好的参考价值，希望对大家有所帮助。一起跟随小编过来看看吧
    2021-01-01
  • PostgreSQL查看带有绑定变量SQL的通用方法详解

    PostgreSQL查看带有绑定变量SQL的通用方法详解

    今天我们要探讨的是 custom执行计划和通用执行计划。这一技术在 Oracle中被称为绑定变量窥视。但 Postgresql中并没有这样的定义，更严格地说，Postgresql叫做custom执行计划和通用执行计划
    2022-09-09
  • PostgreSQL使用MySQL作为外部表(mysql_fdw)

    PostgreSQL使用MySQL作为外部表(mysql_fdw)

    PostgreSQL 提供了一种访问和操作外部数据源的机制，称为外部数据包装器,本文主要给大家介绍了PostgreSQL使用MySQL作为外部表的方法，感兴趣的朋友跟随小编一起看看吧
    2022-11-11
  • PostgreSQL 序列增删改案例

    PostgreSQL 序列增删改案例

    这篇文章主要介绍了PostgreSQL 序列增删改案例，具有很好的参考价值，希望对大家有所帮助。一起跟随小编过来看看吧
    2021-01-01

最新评论