Hi,
Thanks for the review.
> I noticed some things on the first scan through:
>
> Patch 0001:
> 1) Tidy up the comments a bit:
>
> Suggest the following update to part of the comments:
Changed.
> Patch 0002:
> 1) The new max_parallel_hazard_context member "pk_rels" is not being
> set (to
> N
On Tue, Mar 16, 2021 at 8:41 PM houzj.f...@fujitsu.com <
houzj.f...@fujitsu.com> wrote:
>
> > To support parallel insert into FK relation.
> > There are two scenarios need attention.
> > 1) foreign key and primary key are on the same table(INSERT's target
table).
> > (referenced and referencing a
> To support parallel insert into FK relation.
> There are two scenarios need attention.
> 1) foreign key and primary key are on the same table(INSERT's target table).
> (referenced and referencing are the same table)
> 2) referenced and referencing table are both partition of INSERT's target
>
> > After some more on how to support parallel insert into fk relation.
> > It seems we do not have a cheap way to implement this feature.
> >
> > In RI_FKey_check, Currently, postgres execute "select xx for key
> > share" to check that foreign key exists in PK table.
> > However "select for updat
From: Hou, Zhijie/侯 志杰
> After some more on how to support parallel insert into fk relation.
> It seems we do not have a cheap way to implement this feature.
>
> In RI_FKey_check, Currently, postgres execute "select xx for key share" to
> check that foreign key exists in PK table.
> However "sele
> Attaching the first version patch which avoid CCI in RI trigger when insert
> into
> referencing table.
After some more on how to support parallel insert into fk relation.
It seems we do not have a cheap way to implement this feature.
Please see the explanation below:
In RI_FKey_check, Current
> > > I'm worried about having this dependency in RI check, because the
> > > planner
> > may allow parallel INSERT in these cases in the future.
> >
> > If we support parallel insert that can have other modifications in the
> > future, I think we will also be able to share or increment command ID
From: Hou, Zhijie/侯 志杰
> From the wiki[1], CCI is to let statements can not see the rows they modify.
>
> Here is an example of the case 1):
> (Note table referenced and referencing are both empty)
> -
> postgres=# with cte as (insert into referenced values(1)) insert into
> referencing value
> From the wiki[1], CCI is to let statements can not see the rows they modify.
Sorry, a typo here "not".
I meant CCI is to let statements can see the rows they modify.
Best regards,
houzj
Hi,
> Why do we have to increment the command ID when the INSERT's target table
> is a referenced table?
Please refer to the explanation below.
> > And INSERT command only have one target table, the modification on
> > other tables can happen in the following cases.
> >
> > 1) has modifyingcte w
Excuse me for asking probably stupid questions...
From: houzj.f...@fujitsu.com
> As far as I can see, it’s only necessary to increment command id when the
> INSERT command modified the referenced table.
Why do we have to increment the command ID when the INSERT's target table is a
referenced ta
11 matches
Mail list logo