Re: assessing parallel-safety - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: assessing parallel-safety
Date
Msg-id CAA4eK1LB2O_54g_TdXgsmSHbuXMatU-xn_MsO+m6oA8TMdOAew@mail.gmail.com
Whole thread Raw
In response to Re: assessing parallel-safety  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Thu, Mar 19, 2015 at 7:05 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Wed, Feb 18, 2015 at 10:53 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> >
> > On Sun, Feb 15, 2015 at 6:24 PM, Noah Misch <noah@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

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: GSoC 2015: Extra Jsonb functionality
Next
From: Robert Haas
Date:
Subject: Re: Parallel Seq Scan