On Thu, Mar 19, 2015 at 7:05 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Wed, Feb 18, 2015 at 10:53 PM, Robert Haas <robertmh...@gmail.com> wrote: > > > > On Sun, Feb 15, 2015 at 6:24 PM, Noah Misch <n...@leadboat.com> wrote: > > > It's important for parallelism to work under the extended query protocol, and > > > that's nontrivial. exec_parse_message() sets cursorOptions. > > > exec_bind_message() runs the planner. We don't know if a parallel plan is > > > okay before seeing max_rows in exec_execute_message(). > > > > Yes, that's a problem. One could require users of the extended query > > protocol to indicate their willingness to accept a parallel query plan > > when sending the bind message by setting the appropriate cursor > > option; and one could, when that option is specified, refuse execute > > messages with max_rows != 0. However, that has the disadvantage of > > forcing all clients to be updated for the new world order. > > Another way could be when max_rows != 0, then inform executor to > just execute the plan locally, which means run the parallel seq scan
typo /parallel/partial With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com