Re: Inquiry About Determining Parallel Plans for REFRESH MATERIALIZED VIEW - Mailing list pgsql-hackers

From Yugo Nagata
Subject Re: Inquiry About Determining Parallel Plans for REFRESH MATERIALIZED VIEW
Date
Msg-id 20250116150438.e9de52cd8f48bbf88e9c61a0@sraoss.co.jp
Whole thread Raw
In response to Inquiry About Determining Parallel Plans for REFRESH MATERIALIZED VIEW  (Zhang Mingli <zmlpostgres@gmail.com>)
Responses Re: Inquiry About Determining Parallel Plans for REFRESH MATERIALIZED VIEW
List pgsql-hackers
On Thu, 16 Jan 2025 12:39:06 +0800
Zhang Mingli <zmlpostgres@gmail.com> wrote:

> Hi, all
> 
> 
> I am currently exploring the execution of the REFRESH MATERIALIZED VIEW command  and have a specific question
regardingthe underlying query plan. As you know, the REFRESH command is a utility command, and using EXPLAIN
REFRESH doesnot provide a plan structure for analysis.
 
> 
> During development, we want to ascertain whether the SELECT part of the REFRESH command executes with a parallel
plan.While I understand that we can run EXPLAIN on the SELECT statement directly, we are interested in knowing if there
isa method to determine the execution plan under the REFRESH command context.
 
> 
> Currently, we have configured the necessary settings for parallel queries and have been recording the execution time
ofthe REFRESH command to compare parallel and non-parallel executions.
 
> 
> However, I’m looking for a more definitive way to verify if the plan is indeed parallel during the execution of
the REFRESH command.
> 
> Any suggestions?

You will be able to log the plan during the REFRESH by using auto_explain and setting
log_analyze and log_nested_statements to on.

Regards,
Yugo Nagata

-- 
Yugo Nagata <nagata@sraoss.co.jp>



pgsql-hackers by date:

Previous
From: Yugo NAGATA
Date:
Subject: Re: Allow ILIKE forward matching to use btree index
Next
From: Pavel Stehule
Date:
Subject: Re: XMLDocument (SQL/XML X030)