On 10/16/2017 01:13 PM, Amit Kapila wrote: > On Sat, Oct 14, 2017 at 11:44 PM, Tomas Vondra > <tomas.von...@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? >
It may not work, just like for regular cursors without SCROLL. And if you specify SCROLL, then I believe a Materialize node will be added automatically if needed, but haven't tried. > >> >> 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). > I don't like that very much, as it adds unnecessary overhead. As I said before, I'm particularly interested in cursors returning large amounts of data, so the overhead may be quite significant. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
