Re: Parallel Seq Scan

On Sat, Oct 17, 2015 at 12:06 PM, Noah Misch <noah(at)leadboat(dot)com> wrote:
>
> On Sat, Oct 17, 2015 at 11:00:57AM +0530, Amit Kapila wrote:
> > On Sat, Oct 17, 2015 at 6:15 AM, Noah Misch <noah(at)leadboat(dot)com> wrote:
> > > On Thu, Oct 15, 2015 at 04:30:01PM +0530, Amit Kapila wrote:
> > > > On Mon, Oct 12, 2015 at 9:16 PM, Robert Haas <robertmhaas(at)gmail(dot)com>
wrote:
> > > > > plpgsql_param_fetch() assumes that it can detect whether it's
being
> > > > > called from copyParamList() by checking whether params !=
> > > > > estate->paramLI. I don't know why this works, but I do know that
this
> > > > > test fails to detect the case where it's being called from
> > > > > SerializeParamList(), which causes failures in exec_eval_datum()
as
> > > > > predicted. Calls from SerializeParamList() need the same
treatment as
> > > > > calls from copyParamList() because it, too, will try to evaluate
every
> > > > > parameter in the list.
> > > >
> > > > From what I understood by looking at code in this area, I think the
> > check
> > > > params != estate->paramLI and code under it is required for
parameters
> > > > that are setup by setup_unshared_param_list(). Now unshared params
> > > > are only created for Cursors and expressions that are passing a R/W
> > > > object pointer; for cursors we explicitly prohibit the parallel
> > > > plan generation
> > > > and I am not sure if it makes sense to generate parallel plans for
> > > > expressions
> > > > involving R/W object pointer, if we don't generate parallel plan
where
> > > > expressions involve such parameters, then SerializeParamList()
should
> > not
> > > > be affected by the check mentioned by you.
> > >
> > > The trouble comes from the opposite direction. A
setup_unshared_param_list()
> > > list is fine under today's code, but a shared param list needs more
help. To
> > > say it another way, parallel queries that use the shared
estate->paramLI need,
> > > among other help, the logic now guarded by "params !=
estate->paramLI".
> > >
> >
> > Why would a parallel query need such a logic, that logic is needed
mainly
> > for cursor with params and we don't want a parallelize such cases?
>
> This is not about mixing cursors with parallelism. Cursors get special
> treatment because each cursor copies its param list. Parallel query also
> copies (more precisely, serializes) its param list. You need certain
logic
> for every param list subject to being copied.
>

I am not denying from that fact, the point I wanted to convey here is that
the logic guarded by "params != estate->paramLI" in plpgsql_param_fetch
is only needed if cursors are in use otherwise we won't need them even
for parallel query.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com