On Wed, Dec 30, 2020 at 8:03 AM Hou, Zhijie <houzj.f...@cn.fujitsu.com> wrote:
> > 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?
>
> Yes, agreed.
Thanks. Added the test case. Attaching v2 patch. Please have a look.
With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com
From 0d8a3bff5bf35c200bc319eb24151f297044b86a Mon Sep 17 00:00:00 2001
From: Bharath Rupireddy <bharath.rupireddy@enterprisedb.com>
Date: Wed, 30 Dec 2020 09:05:34 +0530
Subject: [PATCH v2] Allow parallel mode in REFRESH MAT VIEW planning
For REFRESH MATERIALIZED VIEW, pass CURSOR_OPT_PARALLEL_OK in
pg_plan_query() so that parallelism can be considered.
---
src/backend/commands/matview.c | 2 +-
src/test/regress/expected/write_parallel.out | 4 ++++
src/test/regress/sql/write_parallel.sql | 4 ++++
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/src/backend/commands/matview.c b/src/backend/commands/matview.c
index cfc63915f3..9bd977d2c7 100644
--- a/src/backend/commands/matview.c
+++ b/src/backend/commands/matview.c
@@ -402,7 +402,7 @@ refresh_matview_datafill(DestReceiver *dest, Query *query,
CHECK_FOR_INTERRUPTS();
/* Plan the query which will generate data for the refresh. */
- plan = pg_plan_query(query, queryString, 0, NULL);
+ plan = pg_plan_query(query, queryString, CURSOR_OPT_PARALLEL_OK, NULL);
/*
* Use a snapshot with an updated command ID to ensure this query sees
diff --git a/src/test/regress/expected/write_parallel.out b/src/test/regress/expected/write_parallel.out
index 0c4da2591a..c4f1f1d18a 100644
--- a/src/test/regress/expected/write_parallel.out
+++ b/src/test/regress/expected/write_parallel.out
@@ -60,6 +60,10 @@ explain (costs off) create materialized view parallel_mat_view as
create materialized view parallel_mat_view as
select length(stringu1) from tenk1 group by length(stringu1);
+-- Allow parallel planning of the underlying query for refresh materialized
+-- view. We can be ensured that parallelism will be picked because of the
+-- enforcement done at the beginning of the test.
+refresh materialized view parallel_mat_view;
drop materialized view parallel_mat_view;
prepare prep_stmt as select length(stringu1) from tenk1 group by length(stringu1);
explain (costs off) create table parallel_write as execute prep_stmt;
diff --git a/src/test/regress/sql/write_parallel.sql b/src/test/regress/sql/write_parallel.sql
index 78b479cedf..db77533e14 100644
--- a/src/test/regress/sql/write_parallel.sql
+++ b/src/test/regress/sql/write_parallel.sql
@@ -32,6 +32,10 @@ explain (costs off) create materialized view parallel_mat_view as
select length(stringu1) from tenk1 group by length(stringu1);
create materialized view parallel_mat_view as
select length(stringu1) from tenk1 group by length(stringu1);
+-- Allow parallel planning of the underlying query for refresh materialized
+-- view. We can be ensured that parallelism will be picked because of the
+-- enforcement done at the beginning of the test.
+refresh materialized view parallel_mat_view;
drop materialized view parallel_mat_view;
prepare prep_stmt as select length(stringu1) from tenk1 group by length(stringu1);
--
2.25.1
