From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, "Adam, Etienne (Nokia-TECH/Issy Les Moulineaux)" <etienne(dot)adam(at)nokia(dot)com>, PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org>, "Duquesne, Pierre (Nokia-TECH/Issy Les Moulineaux)" <pierre(dot)duquesne(at)nokia(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [BUGS] [postgresql 10 beta3] unrecognized node type: 90 |
Date: | 2017-08-28 17:43:22 |
Message-ID: | CA+TgmoabrmBs6WaJtnrkdyAnmcGUcNbsxm=H43Vs9Xj54BCWUA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
On Mon, Aug 28, 2017 at 10:47 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-08-28 19:00:02 | Re: [HACKERS] [postgresql 10 beta3] unrecognized node type: 90 |
Previous Message | Tom Lane | 2017-08-28 16:00:52 | Re: Gin Index Creation Failure |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-08-28 19:00:02 | Re: [HACKERS] [postgresql 10 beta3] unrecognized node type: 90 |
Previous Message | Aaron Patterson | 2017-08-28 17:28:34 | Custom allocators in libpq |