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

Fujii.Yuki@df.MitsubishiElectric.co.jp <
Fujii.Yuki@df.mitsubishielectric.co.jp> 于2024年6月5日周三 09:26写道：

> Hi. Tender.
>
> Thank you for modification.
>
> > From: Tender Wang <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 rel is parallel
safe. Now I haven't come up a query plan that material is un parallel-safe
but rel is parallel-safe.


>
> Sincerely yours,
> Yuuki Fujii
>
> --
> Yuuki Fujii
> Information Technology R&D Center Mitsubishi Electric Corporation
>
>
>

-- 
Tender Wang
OpenPie:  https://en.openpie.com/