Re: INSERT INTO SELECT, Why Parallelism is not selected?

On Tue, Jul 14, 2020 at 1:20 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> On Mon, Jul 13, 2020 at 4:23 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> > I think we can do more than this by
> > parallelizing the Insert part of this query as well as we have lifted
> > group locking restrictions related to RelationExtension and Page lock
> > in PG13. It would be really cool to do that unless we see any
> > fundamental problems with it.
>
> +1, I think it will be cool to support for insert part here as well as
> insert part in 'Create Table As Select..' as well.
>

+1 to parallelize inserts. Currently, ExecInsert() and CTAS use
table_tuple_insert(), if we parallelize these parts, each worker will
be inserting it's tuples(one tuple at a time) into the same data page,
until space is available, if not a new data page can be obtained by
any of the worker, others might start inserting into it. This way,
will there be lock contention on data pages?. Do we also need to make
inserts to use table_multi_insert() (like the way "COPY" uses) instead
of table_tuple_insert()?

With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com