On 4 March 2016 at 09:29, Robert Haas <robertmh...@gmail.com> wrote: > On Thu, Mar 3, 2016 at 2:19 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> This leads me to the conclusion that all these new node types should >> set parallel_aware to false and copy up the other two fields from the >> child, except for LockRows and ModifyTable which should set them all >> to false/0. Correct? If so, I'll go fix. > > Well, I'd probably bubble it up regardless. The fact that the overall > plan writes data will cause everything in the plan to have > parallel_safe = false and parallel_degree = 0, so you'll get the same > outcome either way. However, that way, if writes eventually become > safe, then this won't need adjusting. But it doesn't really matter > much; feel free to do it as you say if you prefer.
This would help me too. I hit a problem with this when adding Group Parallel Aggregate, as the sort path is conditionally added in create_grouping_paths() which causes the parallel_degree for the subpath which is later passed into create_agg_path() to become 0. in create_agg_path() I was using the parallel_degree variable to determine if I should construct a normal serial agg path, or a chain of partial agg -> gather -> final agg paths. To get around the problem I added a parallel_degree parameter to create_agg_path() of which that parameter so far seems to only exist in create_seqscan_path(), which naturally is a bit special as it's a "leaf node" in the path tree. Propagating these would mean I could remove that parameter again. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
