| 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: | Whole Thread | Raw Message | 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
| 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 |