Skip site navigation (1) Skip section navigation (2)

Re: pgsql: Fix calculation of plan node extParams to account for the

From: "Jackie Leng" <lengjianquan(at)163(dot)com>
To: pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql: Fix calculation of plan node extParams to account for the
Date: 2006-06-02 10:05:28
Message-ID: e5p2kr$1905$1@news.hub.org (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
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(at)sss(dot)pgh(dot)pa(dot)us> 
:21744(dot)1149198794(at)sss(dot)pgh(dot)pa(dot)us(dot)(dot)(dot)
> "Jackie Leng" <lengjianquan(at)163(dot)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
>



In response to

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2006-06-02 11:18:24
Subject: Re: 'CVS-Unknown' buildfarm failures?
Previous:From: Dave PageDate: 2006-06-02 09:45:16
Subject: Re: 'CVS-Unknown' buildfarm failures?

pgsql-committers by date

Next:From: Teodor SigaevDate: 2006-06-02 15:35:42
Subject: pgsql: Add more strict check of stop and non-recognized words, allow
Previous:From: Tom LaneDate: 2006-06-01 23:18:11
Subject: pgsql: Back-port Postgres 7.4 spinlock code into 7.3 branch.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group