From: | Luc Vlaming <luc(at)swarm64(dot)com> |
---|---|
To: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, "Hou, Zhijie" <houzj(dot)fnst(at)cn(dot)fujitsu(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Consider Parallelism While Planning For REFRESH MATERIALIZED VIEW |
Date: | 2021-01-04 08:04:16 |
Message-ID: | 3ccd914a-08a2-7d5e-06c1-cc6bc8143de8@swarm64.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 30-12-2020 04:49, Bharath Rupireddy wrote:
> On Wed, Dec 30, 2020 at 8:03 AM Hou, Zhijie <houzj(dot)fnst(at)cn(dot)fujitsu(dot)com> wrote:
>>> Yeah without explain analyze we can not show whether the parallelism is
>>> picked in the test cases. What we could do is that we can add a plain RMV
>>> test case in write_parallel.sql after CMV so that at least we can be ensured
>>> that the parallelism will be picked because of the enforcement there. We
>>> can always see the parallelism for the select part of explain analyze CMV
>>> in write_parallel.sql and the same select query gets planned even in RMV
>>> cases.
>>>
>>> IMO, the patch in this thread can go with test case addition to
>>> write_parallel.sql. since it is very small.
>>>
>>> Thoughts?
>>
>> Yes, agreed.
>
> Thanks. Added the test case. Attaching v2 patch. Please have a look.
>
>
> With Regards,
> Bharath Rupireddy.
> EnterpriseDB: http://www.enterprisedb.com
>
Hi,
Looks good to me and a nice simple improvement.
Passes everything according to http://cfbot.cputube.org/ so marked it
therefore as ready for commiter.
Cheers,
Luc
From | Date | Subject | |
---|---|---|---|
Next Message | Luc Vlaming | 2021-01-04 08:04:34 | Re: Consider Parallelism While Planning For REFRESH MATERIALIZED VIEW |
Previous Message | Luc Vlaming | 2021-01-04 07:59:01 | Re: New Table Access Methods for Multi and Single Inserts |