Re: Parallel Seq Scan - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Parallel Seq Scan
Date
Msg-id CAA4eK1JgP=y2A-Yh7ZBNPztCP3bc1o-fZ+_-OKfC-iBsXnHQvw@mail.gmail.com
Whole thread Raw
In response to Re: Parallel Seq Scan  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Sat, Oct 17, 2015 at 4:54 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Sat, Oct 17, 2015 at 2:44 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> > 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.
>
> Well, I think what Noah and are trying to explain is that this is not
> true.  The problem is that, even if there are no cursors anywhere in
> the picture, there might be some variable in the param list that is
> not used by the parallel query but which, if evaluated, leads to an
> error.
>

I understand what Noah wants to say, it's just that I am not able to see
how that is possible by looking at current code.  The code is not straight
forward in this area, so there is a good chance that I might be missing
something.


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

pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: a raft of parallelism-related bug fixes
Next
From: Tomas Vondra
Date:
Subject: fs issues on software raid0 (PG_VERSION does not contain valid data)