RE: Avoid CommandCounterIncrement in RI trigger when INSERT INTO referencing table

From: Hou, Zhijie/侯 志杰 <houzj(dot)fnst(at)fujitsu(dot)com>
> 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.

Ah, got it. Thank you. I'd regret if Postgres has to give up parallel execution because of SQL statements that don't seem to be used like the above.

> > 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.
> */

Agreed.

I'm excited to see PostgreSQL's parallel DML work in wider use cases and satisfy users' expectations.

Regards
Takayuki Tsunakawa