From: | "Hou, Zhijie" <houzj(dot)fnst(at)cn(dot)fujitsu(dot)com> |
---|---|
To: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | RE: Consider Parallelism While Planning For REFRESH MATERIALIZED VIEW |
Date: | 2020-12-23 03:44:30 |
Message-ID: | 29b4a356e73241ca9ae67a851cf442bc@G08CNEXMBPEKD05.g08.fujitsu.local |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Thanks for taking a look at the patch.
>
> The intention of the patch is to just enable the parallel mode while planning
> the select part of the materialized view, but the insertions do happen in
> the leader backend itself. That way even if there's temporary tablespace
> gets created, we have no problem.
>
> This patch can be thought as a precursor to parallelizing inserts in refresh
> matview. I'm thinking to follow the design of parallel inserts in ctas [1]
> i.e. pushing the dest receiver down to the workers once that gets reviewed
> and finalized. At that time, we should take care of not pushing inserts
> down to workers if temporary tablespace gets created.
>
> In summary, as far as this patch is considered we don't have any problem
> with temporary tablespace getting created with CONCURRENTLY option.
>
> I'm planning to add a few test cases to cover this patch in matview.sql
> and post a v2 patch soon.
Thanks for your explanation!
You are right that temporary tablespace does not affect current patch.
For the testcase:
I noticed that you have post a mail about add explain support for REFRESH MATERIALIZED VIEW.
Do you think we can combine these two features in one thread ?
Personally, The testcase with explain info will be better.
Best regards,
houzj
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2020-12-23 03:57:53 | Re: [Patch] Optimize dropping of relation buffers using dlist |
Previous Message | Dilip Kumar | 2020-12-23 02:59:52 | Re: Parallel bitmap index scan |