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