On Tue, Mar 29, 2016 at 12:48 PM, Paul Ramsey <pram...@cleverelephant.ca> wrote:
>> On the join case, I wonder if it's possible that _st_intersects is not >> marked parallel-safe? If that's not the problem, I don't have a >> second guess, but the thing to do would be to figure out whether >> consider_parallel is false for the RelOptInfo corresponding to either >> of pd and pts, or whether it's true for both but false for the >> joinrel's RelOptInfo, or whether it's true for all three of them but >> you don't get the desired path anyway. > > _st_intersects is definitely marked parallel safe, and in fact will > generate a parallel plan if used alone (without the operator though, > it's impossibly slow). It's the && operator that is the issue... and I > just noticed that the PROCEDURE bound to the && operator > (geometry_overlaps) is *not* marked parallel safe: could be the > problem? Asked and answered: marking the geometry_overlaps as parallel safe gets me a parallel plan! Now to play with costs and see how it behaves when force_parallel_mode is not set. P. > > Thanks, > > P -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
