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
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 |