Re: Inquiry About Determining Parallel Plans for REFRESH MATERIALIZED VIEW
От | Yugo Nagata |
---|---|
Тема | Re: Inquiry About Determining Parallel Plans for REFRESH MATERIALIZED VIEW |
Дата | |
Msg-id | 20250116150438.e9de52cd8f48bbf88e9c61a0@sraoss.co.jp обсуждение исходный текст |
Ответ на | Inquiry About Determining Parallel Plans for REFRESH MATERIALIZED VIEW (Zhang Mingli <zmlpostgres@gmail.com>) |
Ответы |
Re: Inquiry About Determining Parallel Plans for REFRESH MATERIALIZED VIEW
|
Список | 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 по дате отправления: