Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop()

Поиск
Список
Период
Сортировка
От Fujii.Yuki@df.MitsubishiElectric.co.jp"
Тема Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop()
Дата
Msg-id TYAPR01MB308880D964E8C9231A630E5195C72@TYAPR01MB3088.jpnprd01.prod.outlook.com
обсуждение исходный текст
Ответ на Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop()  (Tender Wang <tndrwang@gmail.com>)
Список pgsql-hackers
Hi. Tender.

> From: Tender Wang <tndrwang@gmail.com>
> Sent: Tuesday, June 11, 2024 5:11 PM
> 
>     > From: Tender Wang <tndrwang@gmail.com <mailto:tndrwang@gmail.com> >
>     > Sent: Tuesday, June 4, 2024 7:51 PM
>     >       Please add more tests.  Especially please add some negative tests;
>     >       current patch checks that it is safe to apply materialization. It would
>     >       be helpful to add tests checking that materialization is not applied
>     >       in both checked cases:
>     >       1. when inner join path is not parallel safe
>     >       2. when matpath is not parallel safe
>     >
>     >
>     >
>     > I added a test case that inner rel is not parallel safe. Actually,
>     > matpath will not create if inner rel is not parallel safe. So I didn't add test case for the second  scenario.
>     Is there case in which matpath is not parallel safe and inner rel is parallel safe?
>     If right, I think that it would be suitable to add a negative test in a such case.
> 
> 
> 
> I looked through create_xxx_path(), and I found that almost path.parallel_safe is assigned from
> RelOptiInfo.consider_parallel.
> Some pathes take subpath->parallel_safe into account(e.g. Material path). In most cases, Material is parallel_safe if
relis
 
> parallel safe. Now I haven't come up a query plan that material is un parallel-safe but rel is parallel-safe.
Thank you for looking into the source code. I understand the situation now.

Sincerely yours,
Yuki Fujii

--
Yuki Fujii
Information Technology R&D Center Mitsubishi Electric Corporation

В списке pgsql-hackers по дате отправления:

Предыдущее
От: vignesh C
Дата:
Сообщение: Re: Logical Replication of sequences
Следующее
От: Michail Nikolaev
Дата:
Сообщение: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY