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

Поиск
Список
Период
Сортировка
От Bharath Rupireddy
Тема Re: INSERT INTO SELECT, Why Parallelism is not selected?
Дата
Msg-id CALj2ACU3ye+KxDrUWJJrSqxG9CoQgk7TkgmYUB1iR3W+8QvT1g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: INSERT INTO SELECT, Why Parallelism is not selected?  (Dilip Kumar <dilipbalaut@gmail.com>)
Ответы Re: INSERT INTO SELECT, Why Parallelism is not selected?  (Amit Kapila <amit.kapila16@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: Is it worth accepting multiple CRLs?
Следующее
От: Ashutosh Sharma
Дата:
Сообщение: Re: recovering from "found xmin ... from before relfrozenxid ..."