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

From Robert Haas
Subject Re: assessing parallel-safety
Date
Msg-id CA+TgmoayuYwbAmqzihOkgRVa+FF9JVfNaTABWb6DfggCMXGrbQ@mail.gmail.com
Whole thread Raw
In response to Re: assessing parallel-safety  (Noah Misch <noah@leadboat.com>)
Responses Re: assessing parallel-safety
List pgsql-hackers
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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Resetting crash time of background worker
Next
From: Robert Haas
Date:
Subject: Re: PATCH: pgbench - merging transaction logs