Yes, finalize_plan really has a bms_intersect, but it's used to compute
"plan->extParam":
/* Now we have all the paramids */
if (!bms_is_subset(context.paramids, valid_params))
elog(ERROR, "plan should not reference subplan's variable");
plan->extParam = bms_intersect(context.paramids, outer_params);
plan->allParam = context.paramids;
But what I means is that when we compute "context.paramids", we can filter
out those params refering to a sibling initPlan through bms_intersect, just
like the process to subplan in "finalize_primnode". So, we can change the
following code in finalize_plan. I think it's equivalent to your methods:
case T_SubqueryScan:
/*
* In a SubqueryScan, SS_finalize_plan has already been run on the
* subplan by the inner invocation of subquery_planner, so there's
* no need to do it again. Instead, just pull out the subplan's
* extParams list, which represents the params it needs from my
* level and higher levels.
*/
context.paramids = bms_add_members(context.paramids,
bms_intersect(((SubqueryScan *) plan)->subplan->extParam,
outer_params)); << this line was changed >>
break;
Am I right?
Thank you! :)
"Tom Lane" <tgl@sss.pgh.pa.us> д����Ϣ����
:21744.1149198794@sss.pgh.pa.us...
> "Jackie Leng" <lengjianquan@163.com> writes:
> > So, my question is why not just add a bms_intersect in the second
occasion
> > just like the first one? Do we need to change so much?
>
> finalize_plan already has a bms_intersect, but it's further down in the
> routine (to share code instead of duplicating it in each of the switch
> cases) --- in CVS HEAD, line 1199. This is not relevant to the patch
> AFAICS.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>
