Re: When and how many times does ExecSetParamPlan executes?

From: Vaibhav Kaushal <vaibhavkaushal123(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: When and how many times does ExecSetParamPlan executes?
Date: 2011-03-26 15:10:05
Message-ID: 1301152205.2484.2.camel@localhost
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thanks a lot Mr. Tom.

I understand it better now. I see that the function ExecSetParamPlan is
indeed called only once when executing a query which would have a
paramkind = PARAM_EXEC. The query helped me see the run in debugger,
making things clearer (a lot clearer in fact, especially reading your
last reply again and again).

Thank you again.

Regards,
Vaibhav

On Fri, 2011-03-25 at 15:59 -0400, Tom Lane wrote:
> Vaibhav Kaushal <vaibhavkaushal123(at)gmail(dot)com> writes:
> > So, I think that the function ExecSetParamPlan (as the code suggests
> > too) is called _once_ in any plan/expression and that should be mostly
> > for a sub-select query.
>
> > Kindly correct me if I am wrong. Since I am not able to understand this
> > usecase completely, a sample query which is capable of calling this
> > function (ExecSetParamPlan) could show some light. It would be really
> > kind of you / anyone to show me a query executable through psql which
> > can actually call ExecSetParamPlan and involves the use of a on-disk
> > relation.
>
> regression=# explain verbose select *, (select sum(f1) from int4_tbl) ss from int8_tbl;
> QUERY PLAN
> -----------------------------------------------------------------------------
> Seq Scan on public.int8_tbl (cost=1.07..2.12 rows=5 width=16)
> Output: int8_tbl.q1, int8_tbl.q2, $0
> InitPlan 1 (returns $0)
> -> Aggregate (cost=1.06..1.07 rows=1 width=4)
> Output: sum(int4_tbl.f1)
> -> Seq Scan on public.int4_tbl (cost=0.00..1.05 rows=5 width=4)
> Output: int4_tbl.f1
> (7 rows)
>
> $0 here represents the PARAM_EXEC Param.
>
> regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2011-03-26 15:15:13 Re: Open issues for collations
Previous Message Robert Haas 2011-03-26 15:00:24 Re: race condition in sync rep