From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: assessing parallel-safety |
Date: | 2015-03-17 13:48:23 |
Message-ID: | CA+TgmoayuYwbAmqzihOkgRVa+FF9JVfNaTABWb6DfggCMXGrbQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Mar 17, 2015 at 2:26 AM, Noah Misch <noah(at)leadboat(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-03-17 14:04:09 | Re: PATCH: pgbench - merging transaction logs |
Previous Message | Robert Haas | 2015-03-17 13:42:26 | Re: Resetting crash time of background worker |