From: | Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp> |
---|---|
To: | Zhang Mingli <zmlpostgres(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Inquiry About Determining Parallel Plans for REFRESH MATERIALIZED VIEW |
Date: | 2025-01-16 06:04:38 |
Message-ID: | 20250116150438.e9de52cd8f48bbf88e9c61a0@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 16 Jan 2025 12:39:06 +0800
Zhang Mingli <zmlpostgres(at)gmail(dot)com> 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 EXPLAIN REFRESH does not 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 is a 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 of the 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(at)sraoss(dot)co(dot)jp>
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2025-01-16 06:11:32 | Re: XMLDocument (SQL/XML X030) |
Previous Message | Yugo NAGATA | 2025-01-16 05:53:35 | Re: Allow ILIKE forward matching to use btree index |