> First, I beg to differ with this statement: "Some of the execution > results output are wrong! ...." The point is that > line has loops=4, so as in any other case where loops>1, you're seeing > the number of rows divided by the number of loops. It is the > *average* number of rows that were processed by each loop - one loop > per worker, in this case.
Thanks for the explanation, let my reaction be a guide to what the other unwashed will think :) > Now, on to your actual question: > > I have no idea why the cost adjustments that you need are different > for the scan case and the aggregate case. That does seem problematic, > but I just don't know why it's happening. What might be a good way to debug it? Is there a piece of code I can look at to try and figure out the contribution of COST in either case? > 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? 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
