On Wed, Dec 23, 2020 at 9:14 AM Hou, Zhijie <houzj.f...@cn.fujitsu.com> wrote: > > 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 ?
Yeah, it is at [1] and on some initial analysis ISTM that explain/explain analyze RMV requires a good amount of code rearrangement in ExecRefreshMatView(). IMO these two features can be kept separate because they serve different purposes. [1] - https://www.postgresql.org/message-id/flat/CALj2ACU71s91G1EOzo-Xx7Z4mvF0dKq-mYeP5u4nikJWxPNRSA%40mail.gmail.com > Personally, The testcase with explain info will be better. 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? With Regards, Bharath Rupireddy. EnterpriseDB: http://www.enterprisedb.com
