Re: assessing parallel-safety

On Fri, Mar 20, 2015 at 7:54 PM, Thom Brown <thom@linux.com> wrote:
>
> On 20 March 2015 at 13:55, Thom Brown <thom@linux.com> wrote:
> > On 20 March 2015 at 13:16, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> >> Thom Brown wrote:
> >>> On 18 March 2015 at 16:01, Robert Haas <robertmhaas@gmail.com> wrote:
> >>> > On Tue, Mar 17, 2015 at 9:48 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> >>> >> On Tue, Mar 17, 2015 at 2:26 AM, Noah Misch <noah@leadboat.com> wrote:
> >>> >>> Neither that rule, nor its variant downthread, would hurt operator authors too
> >>> >>> much.  To make the planner categorically parallel-safe, though, means limiting
> >>> >>> evaluate_function() to parallel-safe functions.  That would dramatically slow
> >>> >>> selected queries.  It's enough for the PL scenario if planning a parallel-safe
> >>> >>> query is itself parallel-safe.  If the planner is parallel-unsafe when
> >>> >>> planning a parallel-unsafe query, what would suffer?
> >>> >>
> >>> >> Good point.  So I guess the rule can be that planning a parallel-safe
> >>> >> query should be parallel-safe.  From there, it follows that estimators
> >>> >> for a parallel-safe operator must also be parallel-safe.  Which seems
> >>> >> fine.
> >>> >
> >>> > More work is needed here, but for now, here is a rebased patch, per
> >>> > Amit's request.
> >>>
> >>> This no longer applies due to changes in commit
> >>> 13dbc7a824b3f905904cab51840d37f31a07a9ef.
> >>
> >> You should be able to drop the pg_proc.h changes and run the supplied
> >> perl program.  (I'm not sure that sending the patched pg_proc.h together
> >> with this patch is all that useful, really.)
> >
> > Thanks.  All patches applied and building okay.
>
> Okay, breakage experienced, but not sure which thread this belongs on.
>HEAD Commit-id : 8d1f2390
parallel-mode-v8.1.patch [2]
assess-parallel-safety-v4.patch [1]
parallel-heap-scan.patch [3]
parallel_seqscan_v11.patch (Attached with this mail)