On Fri, Jan 22, 2021 at 7:52 PM tsunakawa.takay@fujitsu.com
<tsunakawa.takay@fujitsu.com> wrote:
>
>
> (1)
> - * (Note that we do allow CREATE TABLE AS, SELECT INTO, and CREATE
> - * MATERIALIZED VIEW to use parallel plans, but as of now, only the leader
> - * backend writes into a completely new table. In the future, we can
> - * extend it to allow workers to write into the table. However, to allow
> - * parallel updates and deletes, we have to solve other problems,
> - * especially around combo CIDs.)
> + * (Note that we do allow CREATE TABLE AS, INSERT INTO...SELECT, SELECT
> + * INTO, and CREATE MATERIALIZED VIEW to use parallel plans. However, as
> + * of now, only the leader backend writes into a completely new table. In
>
> This can read "In INSERT INTO...SELECT case, like other existing cases, only the leader backend writes into a
completelynew table." The reality is that workers as well as the leader can write into an empty or non-empty table in
parallel,isn't it?
>
>
Sorry, I've just realized that this is in reference to the 1st patch
(v12-0001-Enable-parallel-SELECT-for-INSERT-INTO-.-SELECT.patch),
which implements parallel SELECT for INSERT.
In that case, data is SELECTed in parallel by the workers, but only
INSERTed by the parallel leader.
So the patch comment is, in fact, correct.
In the 3rd patch
(v12-0003-Enable-parallel-INSERT-and-or-SELECT-for-INSERT-INTO.patch),
which implements parallel INSERT, the wording for this comment is
again altered, to reflect the fact that parallel workers also write
into the table.
Regards,
Greg Nancarrow
Fujitsu Australia
