Re: parallel plan in insert query

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Grigory Smolkin <g(dot)smolkin(at)postgrespro(dot)ru>
Cc: PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: parallel plan in insert query
Date: 2016-10-11 12:24:41
Message-ID: CAA4eK1JFyx+Q9HBb_dB0_sQh=P7xeLJDOi8rxEdzNiPV4c-bPA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Tue, Oct 11, 2016 at 5:18 PM, Grigory Smolkin
<g(dot)smolkin(at)postgrespro(dot)ru> wrote:
> It`s INSERT:
> 2016-10-07 19:41:41 MSK [11404]: [78416-1]
> user=gis,db=gis,app=psql,client=[local] STATEMENT:
> explain analyze insert into edges_snapped_speeds select gid, speed*3600, ts
> from (select * from traffic_snapped_tracks limit 2) a join lateral
> snaptopgr(geom) on true;
>
> It does qualify query as 'write query'?
>

That's right, but parallelism can be used read part of query. For example,

insert into t1 select * from parallel_exec();

Now if there is some statement in parallel_exec() function, that can
use parallelism.

Example function definition which can use parallelism:
create or replace function parallel_exec() returns integer
as $$
begin
Perform * from t1 where c1 >= 10 and c1 < 11;
return 1;
end;
$$ language plpgsql STABLE PARALLEL SAFE;

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Amit Kapila 2016-10-11 12:58:50 Re: Sudden FTS-related error from parallel worker in 9.6
Previous Message Grigory Smolkin 2016-10-11 11:48:19 Re: parallel plan in insert query