Enable parallelism in REFRESH MATERIALIZED VIEW.
Pass CURSOR_OPT_PARALLEL_OK to pg_plan_query() so that parallel plans
are considered when running the underlying SELECT query. This wasn't
done in commit e9baa5e9
, which did this for CREATE MATERIALIZED VIEW,
because it wasn't yet known to be safe.
Since REFRESH always inserts into a freshly created table before later
merging or swapping the data into place with separate operations, we can
enable such plans here too.
Author: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Reviewed-by: Hou, Zhijie <houzj.fnst@cn.fujitsu.com>
Reviewed-by: Luc Vlaming <luc@swarm64.com>
Reviewed-by: Thomas Munro <thomas.munro@gmail.com>
Discussion: https://postgr.es/m/CALj2ACXg-4hNKJC6nFnepRHYT4t5jJVstYvri%2BtKQHy7ydcr8A%40mail.gmail.com
This commit is contained in:
parent
fbe4cb3bd4
commit
9e7ccd9ef6
|
@ -144,11 +144,27 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
|
|||
The query writes any data or locks any database rows. If a query
|
||||
contains a data-modifying operation either at the top level or within
|
||||
a CTE, no parallel plans for that query will be generated. As an
|
||||
exception, the commands <literal>CREATE TABLE ... AS</literal>, <literal>SELECT
|
||||
INTO</literal>, and <literal>CREATE MATERIALIZED VIEW</literal> which create a new
|
||||
table and populate it can use a parallel plan. Another exception is the command
|
||||
<literal>INSERT INTO ... SELECT ...</literal> which can use a parallel plan for
|
||||
the underlying <literal>SELECT</literal> part of the query.
|
||||
exception, the following commands which create a new table and populate
|
||||
it can use a parallel plan for the underlying <literal>SELECT</literal>
|
||||
part of the query:
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><command>CREATE TABLE ... AS</command></para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><command>SELECT INTO</command></para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><command>INSERT INTO ... SELECT</command></para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><command>CREATE MATERIALIZED VIEW</command></para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><command>REFRESH MATERIALIZED VIEW</command></para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -58,6 +58,9 @@ 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);
|
||||
create unique index on parallel_mat_view(length);
|
||||
refresh materialized view parallel_mat_view;
|
||||
refresh materialized view concurrently 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;
|
||||
|
|
|
@ -30,6 +30,9 @@ 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);
|
||||
create unique index on parallel_mat_view(length);
|
||||
refresh materialized view parallel_mat_view;
|
||||
refresh materialized view concurrently parallel_mat_view;
|
||||
drop materialized view parallel_mat_view;
|
||||
|
||||
prepare prep_stmt as select length(stringu1) from tenk1 group by length(stringu1);
|
||||
|
|
Loading…
Reference in New Issue