On Mon, Jun 27, 2016 at 3:33 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Sun, Jun 26, 2016 at 10:35 PM, Noah Misch <n...@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.
We don't. See ExecSerializePlan(). > 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. I don't really see another option. I don't think it would be a lot of work to pass subplans to workers along with the main plan, but finding all of the places that can then benefit as a result of that change and figuring out which cases are allowable sounds to me like development work, not stabilization. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers