Re: Consider Parallelism While Planning For REFRESH MATERIALIZED VIEW

On Wed, Dec 23, 2020 at 9:14 AM Hou, Zhijie <houzj(dot)fnst(at)cn(dot)fujitsu(dot)com> wrote:
> > Thanks for taking a look at the patch.
> >
> > The intention of the patch is to just enable the parallel mode while planning
> > the select part of the materialized view, but the insertions do happen in
> > the leader backend itself. That way even if there's temporary tablespace
> > gets created, we have no problem.
> >
> > This patch can be thought as a precursor to parallelizing inserts in refresh
> > matview. I'm thinking to follow the design of parallel inserts in ctas [1]
> > i.e. pushing the dest receiver down to the workers once that gets reviewed
> > and finalized. At that time, we should take care of not pushing inserts
> > down to workers if temporary tablespace gets created.
> >
> > In summary, as far as this patch is considered we don't have any problem
> > with temporary tablespace getting created with CONCURRENTLY option.
> >
> > I'm planning to add a few test cases to cover this patch in matview.sql
> > and post a v2 patch soon.
>
> Thanks for your explanation!
> You are right that temporary tablespace does not affect current patch.
>
> For the testcase:
> I noticed that you have post a mail about add explain support for REFRESH MATERIALIZED VIEW.
> Do you think we can combine these two features in one thread ?

Yeah, it is at [1] and on some initial analysis ISTM that
explain/explain analyze RMV requires a good amount of code
rearrangement in ExecRefreshMatView(). IMO these two features can be
kept separate because they serve different purposes.

[1] - https://www.postgresql.org/message-id/flat/CALj2ACU71s91G1EOzo-Xx7Z4mvF0dKq-mYeP5u4nikJWxPNRSA%40mail.gmail.com

> Personally, The testcase with explain info will be better.

Yeah without explain analyze we can not show whether the parallelism
is picked in the test cases. What we could do is that we can add a
plain RMV test case in write_parallel.sql after CMV so that at least
we can be ensured that the parallelism will be picked because of the
enforcement there. We can always see the parallelism for the select
part of explain analyze CMV in write_parallel.sql and the same select
query gets planned even in RMV cases.

IMO, the patch in this thread can go with test case addition to
write_parallel.sql. since it is very small.

Thoughts?

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