Re: Inquiry About Determining Parallel Plans for REFRESH MATERIALIZED VIEW

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>

In response to

Responses

Browse pgsql-hackers by date

  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