Re: [PoC] Asynchronous execution again (which is not parallel)
| От | Amit Kapila |
|---|---|
| Тема | Re: [PoC] Asynchronous execution again (which is not parallel) |
| Дата | |
| Msg-id | CAA4eK1JVU4ySNzF-ZFpQPxQN1KDHTVOsaWxTXMBDNmNnPzCbWQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [PoC] Asynchronous execution again (which is not parallel) (Robert Haas <robertmhaas@gmail.com>) |
| Список | pgsql-hackers |
On Wed, Dec 16, 2015 at 6:04 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Wed, Dec 16, 2015 at 1:34 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> > Yes, thats one thing I wanted to know, yet another point which is not
> > clear to me about this Async infrastructure is why the current
> > infrastructure
> > of Parallelism can't be used to achieve the Async benefits of ForeignScan?
>
> Well, all a ForeignScan by postgres_fdw does is read the tuples that
> are generated remotely. Turning around and sticking those into a
> Funnel doesn't seem like it gains much: now instead of having to read
> tuples from someplace, the leader has to read tuples from some other
> place. Yeah, there are cases where it could win, like when there's a
> selective nonpushable qual, but that's not that exciting.
>
>
> On Wed, Dec 16, 2015 at 1:34 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> > Yes, thats one thing I wanted to know, yet another point which is not
> > clear to me about this Async infrastructure is why the current
> > infrastructure
> > of Parallelism can't be used to achieve the Async benefits of ForeignScan?
>
> Well, all a ForeignScan by postgres_fdw does is read the tuples that
> are generated remotely. Turning around and sticking those into a
> Funnel doesn't seem like it gains much: now instead of having to read
> tuples from someplace, the leader has to read tuples from some other
> place. Yeah, there are cases where it could win, like when there's a
> selective nonpushable qual, but that's not that exciting.
>
> There's another, more serious problem: if the leader has a connection
> open to the remote server and that connection is in mid-transaction,
> you can't have a worker open a new connection without changing the
> semantics. Working around that problem looks hard to me.
>
> open to the remote server and that connection is in mid-transaction,
> you can't have a worker open a new connection without changing the
> semantics. Working around that problem looks hard to me.
>
Okay. It seems there are cases where it could benefit from Async
execution infrastructure instead of directly using Gather node kind
of infrastructure. I am not the right person to judge whether there
are enough cases that we need a new infrastructure for such executions,
but I think it is a point to consider and I am sure you will make the
right move.
В списке pgsql-hackers по дате отправления: