On Mon, Aug 28, 2017 at 10:47 AM, Tom Lane <tgl@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