On 20 March 2015 at 13:16, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > Thom Brown wrote: >> On 18 March 2015 at 16:01, Robert Haas <robertmh...@gmail.com> wrote: >> > On Tue, Mar 17, 2015 at 9:48 AM, Robert Haas <robertmh...@gmail.com> wrote: >> >> On Tue, Mar 17, 2015 at 2:26 AM, Noah Misch <n...@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. -- Thom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
