Re: [HACKERS] PATCH: enabling parallel execution for cursorsexplicitly (experimental)
От | Amit Kapila |
---|---|
Тема | Re: [HACKERS] PATCH: enabling parallel execution for cursorsexplicitly (experimental) |
Дата | |
Msg-id | CAA4eK1JuwbvH_+yqm1=ZXqBw5uxg59GdKs8tdw6an4VTqwWRYg@mail.gmail.com обсуждение исходный текст |
Ответ на | [HACKERS] PATCH: enabling parallel execution for cursors explicitly(experimental) (Tomas Vondra <tomas.vondra@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] PATCH: enabling parallel execution for cursorsexplicitly (experimental)
|
Список | pgsql-hackers |
On Sat, Oct 14, 2017 at 11:44 PM, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote: > Hi, > > > I propose is to add a new cursor option (PARALLEL), which would allow > parallel plans for that particular user-defined cursor. Attached is an > experimental patch doing this (I'm sure there are some loose ends). > How will this work for backward scans? > > Regarding (2), if the user suspends the cursor for a long time, bummer. > The parallel workers will remain assigned, doing nothing. I don't have > any idea how to get around that, but I don't see how we could do better. > One idea could be that whenever someone uses Parallel option, we can fetch and store all the data locally before returning control to the user (something like WITH HOLD option). -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления: