Re: Parallel INSERT (INTO ... SELECT ...) - Mailing list pgsql-hackers

From Greg Nancarrow
Subject Re: Parallel INSERT (INTO ... SELECT ...)
Date
Msg-id CAJcOf-fd51zqtCOGCWa7=Gjx8Lh9nAApY6Q0rUq9hAfY1M4Msg@mail.gmail.com
Whole thread Raw
In response to RE: Parallel INSERT (INTO ... SELECT ...)  ("Hou, Zhijie" <houzj.fnst@cn.fujitsu.com>)
List pgsql-hackers
On Mon, Feb 8, 2021 at 6:00 PM Hou, Zhijie <houzj.fnst@cn.fujitsu.com> wrote:
>
> > Posting an updated set of patches.
>
> A minor comment about doc.
>
> +  <para>
> +    Where the above target table features are determined to be, at worst,
> +    parallel-restricted, rather than parallel-unsafe, at least a parallel table
> +    scan may be used in the query plan for the <literal>INSERT</literal>
> +    statement. For more information about Parallel Safety, see
> +    <xref linkend="parallel-safety"/>.
> +  </para>
>
> It seems does not mention that if target table is a foreign/temp table, a parallel table scan may be used.
>
> So how about:
>
> +  <para>
> +    Where the target table is a foreign/temporary table or the above target table features
> +    are determined to be, at worst, parallel-restricted, rather than parallel-unsafe,
> +    at least a parallel table scan may be used in the query plan for the
> +    <literal>INSERT</literal> statement. For more information about Parallel Safety,
> +    see <xref linkend="parallel-safety"/>.
> +  </para>
>

Thanks. You're right, I should probably update the docs to clarify
those two cases.
(I had removed them from the list of parallel-unsafe things, but not
pointed out that a parallel table scan could still be used in these
cases).

Regards,
Greg Nancarrow
Fujitsu Australia



pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: Support tab completion for upper character inputs in psql
Next
From: Andy Fan
Date:
Subject: Re: cost_sort vs cost_agg