On Sat, Oct 14, 2017 at 2:14 PM, Tomas Vondra <tomas.von...@2ndquadrant.com> wrote: > 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).
I think you would need to do a huge amount of additional work in order to actually make this robust. I believe that a fair amount of what goes on in parallel mode right now is checked with elog() if we think that it's unreachable without writing C code -- but this will make a lot of those things reachable, which means they would need to be checked some other way. Also, I doubt this guarantees that we won't try to call parallel-unsafe functions will parallel mode is active, so things will just blow up in whatever way they do, maybe crashing the server or rendering the database inconsistent or whatever. Possibly I'm overestimating the extent of the danger, but I don't think so. You're try to take a mechanism that was only ever meant to be active during the course of one query and applying it for long periods of time during which a user can do anything, with basically no upgrade of the infrastructure. I think something like this could be made to work if you put a large amount of energy into it, but I think the patch as proposed is about the easiest 3-5% of what would actually be required to cover all the holes. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers