> 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