Re: assessing parallel-safety
От | Noah Misch |
---|---|
Тема | Re: assessing parallel-safety |
Дата | |
Msg-id | 20150213051038.GA3904350@tornado.leadboat.com обсуждение исходный текст |
Ответ на | Re: assessing parallel-safety (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: assessing parallel-safety
|
Список | pgsql-hackers |
On Thu, Feb 12, 2015 at 07:40:12AM -0500, Robert Haas wrote: > On Thu, Feb 12, 2015 at 12:16 AM, Noah Misch <noah@leadboat.com> wrote: > > That is a major mark against putting the check in simplify_function(), agreed. > > I do see one way to rescue that idea, which is this: put two flags, > parallelModeOK and parallelModeRequired, into PlannerGlobal. At the > beginning of planning, set parallelModeOK based on our best knowledge > at that time; as we preprocess expressions, update it to false if we > see something that's not parallel-safe. Emit paths for parallel plans > only if the flag is currently true. At the end of planning, when we > convert paths to plans, set parallelModeRequired if any parallel plan > elements are generated. If we started with parallelModeOK = true or > ended up with parallelModeRequired = false, then life is good. In the > unfortunate event that we end up with parallelModeOK = false and > parallelModeRequired = true, replan, this time with parallelModeOK = > false from the beginning. > So this would mostly be pretty cheap, but if you do hit the case where > a re-plan is required it would be pretty painful. > >> > Unless we want to rejigger this so that we do a > >> > complete eval_const_expressions() pass over the entire query tree > >> > (including all subqueries) FIRST, and then only after that go back and > >> > plan all of those subqueries, I don't see how to make this work; and > >> > I'm guessing that there are good reasons not to do that. > > > > I expect that would work fine, but I do think it premature to venture that far > > out of your way to optimize this new tree examination. Given your wish to optimize, I recommend first investigating the earlier thought to issue eval_const_expressions() once per planner() instead of once per subquery_planner(). Compared to the parallelModeRequired/parallelModeOK idea, it would leave us with a more maintainable src/backend/optimizer. I won't object to either design, though. Your survey of parallel safety among built-in functions was on-target.
В списке pgsql-hackers по дате отправления: