Re: Parallel Seq Scan
| От | Amit Kapila |
|---|---|
| Тема | Re: Parallel Seq Scan |
| Дата | |
| Msg-id | CAA4eK1JgP=y2A-Yh7ZBNPztCP3bc1o-fZ+_-OKfC-iBsXnHQvw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Parallel Seq Scan (Robert Haas <robertmhaas@gmail.com>) |
| Список | 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
>
> 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.
В списке pgsql-hackers по дате отправления: