On Mon, Aug 28, 2017 at 10:47 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > That seems like an unacceptably fragile assumption. Even if it happens to > be true today, we would need to fix it sooner or later. (And I kinda > suspect it's possible to break it today, anyway. Treating PARAM_EXEC > Params as parallel-restricted seems to lock out the easiest cases, but we > have param slots that don't correspond to any Param node, eg for recursive > union worktables. replace_nestloop_params is also a source of PARAM_EXEC > Params that won't be detected during is_parallel_safe() tests, because it > happens later.)
Those particular cases are, I think, handled. The CTE case is handled by considering CTE scans as parallel-restricted, and the nestloop case is handled by insisting that all partial paths must be unparameterized. You can join a partial path to a parameterized non-partial path to make a new partial path, but neither the original partial path nor the resulting one can itself be parameterized. - fuller description. Academic literature on parallel query suggests that + fuller description. The academic literature on parallel query suggests That sentence isn't wrong as written. I don't really understand the part about depending on a parallel-aware node. I mean, there should always be one, except in the single-copy-Gather case, but why is it right to depend on that rather than anything else? What happens when the Parallel Hash patch goes in and we have multiple parallel-aware scan nodes (plus a parallel-aware Hash node) under the same Gather? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
