Re: Inquiry About Determining Parallel Plans for REFRESH MATERIALIZED VIEW

2025-01-15 Thread jian he
On Thu, Jan 16, 2025 at 3:05 PM Zhang Mingli wrote: > > > 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

Re: Inquiry About Determining Parallel Plans for REFRESH MATERIALIZED VIEW

2025-01-15 Thread Zhang Mingli
Hi Zhang Mingli www.hashdata.xyz On Jan 16, 2025 at 14:04 +0800, Yugo Nagata , 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

Re: Inquiry About Determining Parallel Plans for REFRESH MATERIALIZED VIEW

2025-01-15 Thread Yugo Nagata
On Thu, 16 Jan 2025 12:39:06 +0800 Zhang Mingli wrote: > Hi, all > > > I am currently exploring the execution of the REFRESH MATERIALIZED VIEW  > command  and have a specific question regarding the underlying query plan. As > you know, the REFRESH command is a utility command, and using EXPLAI

Inquiry About Determining Parallel Plans for REFRESH MATERIALIZED VIEW

2025-01-15 Thread Zhang Mingli
Hi, all I am currently exploring the execution of the REFRESH MATERIALIZED VIEW command   and have a specific question regarding the underlying query plan. As you know, the REFRESH command is a utility command, and using EXPLAIN REFRESH does not provide a plan structure for analysis. During de