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

From Zhang Mingli
Subject Re: Inquiry About Determining Parallel Plans for REFRESH MATERIALIZED VIEW
Date
Msg-id df288329-1e2e-4fc2-9b20-c91f3a195036@Spark
Whole thread Raw
In response to Re: Inquiry About Determining Parallel Plans for REFRESH MATERIALIZED VIEW  (Yugo Nagata <nagata@sraoss.co.jp>)
Responses Re: Inquiry About Determining Parallel Plans for REFRESH MATERIALIZED VIEW
List pgsql-hackers
Hi


Zhang Mingli
www.hashdata.xyz
On Jan 16, 2025 at 14:04 +0800, Yugo Nagata <nagata@sraoss.co.jp>, wrote:

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.

Hi Yugo,

Thank you for your help! That’s certainly a viable approach to logging the plan during the REFRESH operation.
However, I want to clarify that we’re particularly interested in examining the SQL cases. When there are numerous queries that may also include REFRESH, it can be challenging to sift through the logs and identify the specific query we want to analyze using SQL.

Ideally, it would be beneficial if we could obtain an explanation of the SQL associated with a REFRESH command, allowing us to see the SELECT plan without having to execute the REFRESH itself. 
We could limit EXPLAIN utility command to only REFRESH , on the AS SELECT part, similar to how we can with CREATE TABLE AS, is it possible and worthwhile?

pgsql-hackers by date:

Previous
From: Bertrand Drouvot
Date:
Subject: Re: per backend I/O statistics
Next
From: Nisha Moond
Date:
Subject: Re: Introduce XID age and inactive timeout based replication slot invalidation