On Mon, Nov 21, 2016 at 12:00 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Mon, Nov 21, 2016 at 11:43 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> so what we've got is a case where a parameter computed by the FunctionScan >>> (in the master) would need to be passed into the parallel workers at >>> runtime. Do we have code for that at all? If so where is it? > >> No, that's not supposed to happen. > > OK, that makes this a planner failure: we should not have allowed this > query to become parallelized. > >> Maybe it's checking the quals but not recursing into the tlist? > > It seems like maybe searching for individual Params is the wrong thing. > Why are we allowing it to generate a parameterized Gather path at all? > Given the lack of any way to transmit runtime param values to the worker, > I can't see how that would ever work.
Hmm, so you're thinking it could be the job of generate_gather_paths() to make sure we don't do that? -- 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
