On Thu, Jun 16, 2016 at 8:00 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: >> 1. The case originally reported by Thomas Munro still fails. To fix >> that, we probably need to apply scanjoin_target to each partial path. >> But we can only do that if it's parallel-safe. It seems like what we >> want is something like this: (1) During scan/join planning, somehow >> skip calling generate_gather_paths for the topmost scan/join rel as we >> do to all the others. (2) If scanjoin_target is not parallel-safe, >> build a path for the scan/join phase that applies a Gather node to the >> cheapest path and does projection at the Gather node. Then forget all >> the partial paths so we can't do any bogus upper planning. (3) If >> scanjoin_target is parallel-safe, replace the list of partial paths >> for the topmost scan/join rel with a new list where scanjoin_target >> has been applied to each one. I haven't tested this so I might be >> totally off-base about what's actually required here... > > I think we can achieve it just by doing something like what you have > mentioned in (2) and (3). I am not sure if there is a need to skip > generation of gather paths for top scan/join node. Please see the patch > attached. I have just done some minimal testing to ensure that problem > reported by Thomas Munro in this thread is fixed and verified that the fix > is sane for problems  reported by sqlsmith. If you think this is on > right lines, I can try to do more verification and try to add tests.
You can't do it this way because of the issue Tom discussed here: https://www.postgresql.org/message-id/16421.1465828...@sss.pgh.pa.us -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers