Re: MinMaxAggPath vs. parallel-safety
От | Tom Lane |
---|---|
Тема | Re: MinMaxAggPath vs. parallel-safety |
Дата | |
Msg-id | 16555.1467056002@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | MinMaxAggPath vs. parallel-safety (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: MinMaxAggPath vs. parallel-safety
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Sun, Jun 26, 2016 at 10:35 PM, Noah Misch <noah@leadboat.com> wrote: >> The above-described topic is currently a PostgreSQL 9.6 open item ("consider >> whether MinMaxAggPath might fail to be parallel-safe"). > Currently, MinMaxAggPath is never parallel-safe; the question is > whether we could allow it to be parallel-safe (not, as the current > phrasing implies, whether it might ever need to be other than > parallel-safe). Check. > It appears to me that the answer is "no", because a > MinMaxAggPath contains a list of MinMaxAggInfo objects, and there we > have this: > Param *param; /* param for subplan's output */ > Since subplans aren't passed down to parallel workers, no > MinMaxAggPath can be parallel-safe. Therefore, I think there's > nothing to do here right now. Comments? Hm. In principle, this could be made to work, since I don't think it would be necessary for the Param's value to pass across process boundaries. (It could be locally generated within a worker, and then also consumed within the worker, if the worker's plan looked like a Result with a subplan attached.) However, if we don't even pass down the plan trees for subplans, then I agree that it can't work at the moment. In any case, this is an optimization opportunity not a bug. If you want to kick this can down the road until parallel query is generally smarter about subplans, that's OK with me. regards, tom lane
В списке pgsql-hackers по дате отправления: