Return to Question

I am wondering whether CREATE (with data) or REFRESH MATERIALIZED VIEW uses the parallel planner. When I EXPLAIN ANALYZE the query by itself (any query with parallel potential works here) without creating the materialized view, it shows that said query is parallel aware, and executing said query by itself shows multiple processors active using standard Linux tools like top.

Conversely, executing the query within a REFRESH or CREATE materialized view wrapper, does not show multiple processes, and using EXPLAIN on CREATE MATERIALIZED VIEW shows a query that is not parallel aware. Is this intentional behavior and why? I was not able to find any information on this. (PostgreSQL 10.5 on CentOS 7)

EDIT 1: Checked that this behavior is the same when using CREATE TABLE AS and SELECT INTO. Is there any way to write a table using parallelism?

EDIT 2: Is there any workaround I can use to CREATE TABLE using parallelism without first outputting the results of the query to a file? Such as somehow splitting the query into several hundred equal parts defined by an aggregation variable in the data, followed by a specified number of cores in parts getting INSERT'ed in parallel?

I am wondering whether CREATE (with data) or REFRESH MATERIALIZED VIEW uses the parallel planner. When I EXPLAIN ANALYZE the query by itself (any query with parallel potential works here) without creating the materialized view, it shows that said query is parallel aware, and executing said query by itself shows multiple processors active using standard Linux tools like top.

Conversely, executing the query within a REFRESH or CREATE materialized view wrapper, does not show multiple processes, and using EXPLAIN on CREATE MATERIALIZED VIEW shows a query that is not parallel aware. Is this intentional behavior and why? I was not able to find any information on this. (PostgreSQL 10.5 on CentOS 7)

Checked that this behavior is the same when using CREATE TABLE AS and SELECT INTO. Is there any way to write a table using parallelism?

Is there any workaround I can use to CREATE TABLE using parallelism without first outputting the results of the query to a file? Such as somehow splitting the query into several hundred equal parts defined by an aggregation variable in the data, followed by a specified number of cores in parts getting INSERT'ed in parallel?

I am wondering whether CREATE (with data) or REFRESH MATERIALIZED VIEW uses the parallel planner? When I EXPLAIN ANALYZE the query by itself (any query with parallel potential works here) without creating the materialized view, it shows that said query is parallel aware, and executing said query by itself shows multiple processors active using standard linux tools like top. Conversely, executing the query within a REFRESH or CREATE materialized view wrapper, does not show multiple processes, and using EXPLAIN on CREATE MATERIALIZED VIEW shows a query that is not parallel aware. Is this the intentional behavior and why? I was not able to find any information on this. (PostgreSQL 10.5 on CentOS 7)

EDIT: Checked that this behavior is the same when using CREATE TABLE AS and SELECT INTO. Is there any way to write a table using parallelism?

EDIT 2: Is there any work-around I can use to CREATE TABLE using parallelism without first outputting the results of query to a file? Such as somehow splitting the query into several hundred equal parts defined by a aggregation variable in the data, followed by a specified number of cores in parts getting INSERT'ed in parallel?

I am wondering whether CREATE (with data) or REFRESH MATERIALIZED VIEW uses the parallel planner. When I EXPLAIN ANALYZE the query by itself (any query with parallel potential works here) without creating the materialized view, it shows that said query is parallel aware, and executing said query by itself shows multiple processors active using standard Linux tools like top. 

Conversely, executing the query within a REFRESH or CREATE materialized view wrapper, does not show multiple processes, and using EXPLAIN on CREATE MATERIALIZED VIEW shows a query that is not parallel aware. Is this intentional behavior and why? I was not able to find any information on this. (PostgreSQL 10.5 on CentOS 7)

EDIT 1: Checked that this behavior is the same when using CREATE TABLE AS and SELECT INTO. Is there any way to write a table using parallelism?

EDIT 2: Is there any workaround I can use to CREATE TABLE using parallelism without first outputting the results of the query to a file? Such as somehow splitting the query into several hundred equal parts defined by an aggregation variable in the data, followed by a specified number of cores in parts getting INSERT'ed in parallel?