On Tue, Feb 23, 2016 at 2:06 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>>> Foreign tables are supposed to be categorically excluded from
>>> parallelism. Not sure why that's not working in this instance.
>
> BTW, I wonder where you think that's supposed to be enforced, because
> I sure can't find any such logic.
>
> I suppose that has_parallel_hazard() would be the logical place to
> notice foreign tables, but it currently doesn't even visit RTEs,
> much less contain any code to check if their tables are foreign.
> Or did you have another place in mind to do that?
RTEs are checked in set_rel_consider_parallel(), and I thought there
was a check there related to foreign tables, but there isn't. Oops.
In view of 69d34408e5e7adcef8ef2f4e9c4f2919637e9a06, we shouldn't
blindly assume that foreign scans are not parallel-safe, but we can't
blindly assume the opposite either. Maybe we should assume that the
foreign scan is parallel-safe only if one or more of the new methods
introduced by the aforementioned commit are set, but actually that
doesn't seem quite right. That would tell us whether the scan itself
can be parallelized, not whether it's safe to run serially but within
a parallel worker. I think maybe we need a new FDW API that gets
called from set_rel_consider_parallel() with the root, rel, and rte as
arguments and which can return a Boolean. If the callback is not set,
assume false.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company