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 which modifies the referenced table > > 2) has modifying function which modifies the referenced table. > > (If I missed something please let me know) > > Also, why do we need CCI in these cases? What kind of problem would > happen if we don't do CCI? >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 values(1); ----- The INSERT here will first modify the referenced table(pk table) and then modify the referencing table. When modifying the referencing table, it has to check if the tuple to be insert exists in referenced table. At this moment, CCI can let the modification on referenced in WITH visible when check the existence of the tuple. If we do not CCI here, postgres will report an constraint error because it can not find the tuple in referenced table. What do you think? > > Since the above two cases are not supported in parallel mode(parallel > unsafe). > > IMO, It seems it’s not necessary to increment command id in parallel > > mode, we can just skip commandCounterIncrement when in parallel mode. > > > > + /* > > + * We do not need to increment the command counter > > + * in parallel mode, because any other modifications > > + * other than the insert event itself are parallel unsafe. > > + * So, there is no chance to modify the pk relation. > > + */ > > + if (IsInParallelMode()) > > + needCCI = false; > 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 in parallel wokers in that time. And it seems we can remove this dependency in that time. How about add some more comments about this to remind future developer. /* * If extra parallel modification is support in the future, this dependency should be removed. */ [1] https://wiki.postgresql.org/wiki/Developer_FAQ#What_is_CommandCounterIncrement.28.29.3F Best regards, houzj
