Re: [HACKERS] PATCH: enabling parallel execution for cursorsexplicitly (experimental) - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: [HACKERS] PATCH: enabling parallel execution for cursorsexplicitly (experimental)
Date
Msg-id CAA4eK1JuwbvH_+yqm1=ZXqBw5uxg59GdKs8tdw6an4VTqwWRYg@mail.gmail.com
Whole thread Raw
In response to [HACKERS] PATCH: enabling parallel execution for cursors explicitly(experimental)  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: [HACKERS] PATCH: enabling parallel execution for cursorsexplicitly (experimental)
List 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 by date:

Previous
From: Amit Kapila
Date:
Subject: Re: [HACKERS] Parallel safety for extern params
Next
From: Ashutosh Bapat
Date:
Subject: Re: [HACKERS] Partition-wise join for join between (declaratively)partitioned tables