Re: INSERT INTO SELECT, Why Parallelism is not selected? - Mailing list pgsql-hackers

From Bharath Rupireddy
Subject Re: INSERT INTO SELECT, Why Parallelism is not selected?
Date
Msg-id CALj2ACU3ye+KxDrUWJJrSqxG9CoQgk7TkgmYUB1iR3W+8QvT1g@mail.gmail.com
Whole thread Raw
In response to Re: INSERT INTO SELECT, Why Parallelism is not selected?  (Dilip Kumar <dilipbalaut@gmail.com>)
Responses Re: INSERT INTO SELECT, Why Parallelism is not selected?
List pgsql-hackers
On Tue, Jul 14, 2020 at 1:20 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> On Mon, Jul 13, 2020 at 4:23 PM Amit Kapila <amit.kapila16@gmail.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



pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: Is it worth accepting multiple CRLs?
Next
From: Ashutosh Sharma
Date:
Subject: Re: recovering from "found xmin ... from before relfrozenxid ..."