Re: Consider Parallelism While Planning For REFRESH MATERIALIZED VIEW

On Tue, Dec 22, 2020 at 4:53 PM Hou, Zhijie <houzj.fnst@cn.fujitsu.com> wrote:
> I have an issue about the safety of enable parallel select.
>
> I checked the [parallel insert into select] patch.
> https://commitfest.postgresql.org/31/2844/
> It seems parallel select is not allowed when target table is temporary table.
>
> +       /*
> +        * We can't support table modification in parallel-mode if it's a foreign
> +        * table/partition (no FDW API for supporting parallel access) or a
> +        * temporary table.
> +        */
> +       if (rel->rd_rel->relkind == RELKIND_FOREIGN_TABLE ||
> +               RelationUsesLocalBuffers(rel))
> +       {
> +               table_close(rel, lockmode);
> +               context->max_hazard = PROPARALLEL_UNSAFE;
> +               return context->max_hazard;
> +       }
>
> For Refresh MatView.
> if CONCURRENTLY is specified, It will builds new data in temp tablespace:
>         if (concurrent)
>         {
>                 tableSpace = GetDefaultTablespace(RELPERSISTENCE_TEMP, false);
>                 relpersistence = RELPERSISTENCE_TEMP;
>         }
>
> For the above case, should we still consider parallelism ?

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.

[1] -  https://www.postgresql.org/message-id/CALj2ACWbQ95gS0z1viQC3qFVnMGAz7dcLjno9GdZv%2Bu9RAU9eQ%40mail.gmail.com

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