On Tue, Mar 16, 2021 at 2:41 PM Thomas Munro wrote:
> On Mon, Mar 15, 2021 at 8:25 PM Bharath Rupireddy
> wrote:
> > > > The problem with a case like REFRESH MATERIALIZED VIEW is that there's
> > > > nothing to prevent something that gets run in the course of the query
> > > > from trying to acce
On Mon, Mar 15, 2021 at 8:25 PM Bharath Rupireddy
wrote:
> > > The problem with a case like REFRESH MATERIALIZED VIEW is that there's
> > > nothing to prevent something that gets run in the course of the query
> > > from trying to access the view (and the heavyweight lock won't prevent
> > > that,
On Mon, Mar 15, 2021 at 10:38 AM Thomas Munro wrote:
> While reading some back history, I saw that commit e9baa5e9 introduced
> parallelism for CREATE M V, but REFRESH was ripped out of the original
> patch by Robert, who said:
>
> > The problem with a case like REFRESH MATERIALIZED VIEW is that t
On Mon, Mar 15, 2021 at 10:39 AM Thomas Munro wrote:
>
> On Mon, Jan 4, 2021 at 9:05 PM Luc Vlaming wrote:
>
> While reading some back history, I saw that commit e9baa5e9 introduced
> parallelism for CREATE M V, but REFRESH was ripped out of the original
> patch by Robert, who said:
>
> > The pro
On Mon, Jan 4, 2021 at 9:05 PM Luc Vlaming wrote:
> The new status of this patch is: Ready for Committer
I think the comments above this might as well be removed, because they
aren't very convincing:
+-- Allow parallel planning of the underlying query for refresh materialized
+-- view. We can be
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
passes according to http://cfbot.cputube.org/
The new status of this
On 30-12-2020 04:49, Bharath Rupireddy wrote:
On Wed, Dec 30, 2020 at 8:03 AM Hou, Zhijie 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
On Wed, Dec 30, 2020 at 8:03 AM Hou, Zhijie 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
> 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
On Wed, Dec 23, 2020 at 9:14 AM Hou, Zhijie 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
> 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
On Tue, Dec 22, 2020 at 4:53 PM Hou, Zhijie wrote:
> I have an issue about the safety of enable parallel select.
>
> I checked the [parallel insert into select] patch.
> https://commitfest.postgresql.org/31/2844/
> It seems parallel select is not allowed when target table is temporary table.
>
> +
Hi
> Added this to commitfest, in case it is useful -
> https://commitfest.postgresql.org/31/2856/
I have an issue about the safety of enable parallel select.
I checked the [parallel insert into select] patch.
https://commitfest.postgresql.org/31/2844/
It seems parallel select is not allowed whe
On Tue, Dec 1, 2020 at 5:34 PM Bharath Rupireddy
wrote:
>
> Hi,
>
> I think we can pass CURSOR_OPT_PARALLEL_OK to pg_plan_query() for
> refresh mat view so that parallelism can be considered for the SELECT
> part of the previously created mat view. The refresh mat view queries
> can be faster in c
Hi,
I think we can pass CURSOR_OPT_PARALLEL_OK to pg_plan_query() for
refresh mat view so that parallelism can be considered for the SELECT
part of the previously created mat view. The refresh mat view queries
can be faster in cases where SELECT is parallelized.
Attaching a small patch. Thoughts?
15 matches
Mail list logo
