Re: Parallel Queries and PostGIS

On Fri, Apr 1, 2016 at 12:49 AM, Paul Ramsey <pramsey(at)cleverelephant(dot)ca>
wrote:
>
> On Tue, Mar 29, 2016 at 12:51 PM, Paul Ramsey <pramsey(at)cleverelephant(dot)ca>
wrote:
> > On Tue, Mar 29, 2016 at 12:48 PM, Paul Ramsey <pramsey(at)cleverelephant(dot)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.
>
> For the record I can get a non-forced parallel join plan, *only* if I
> reduce the parallel_join_cost by a factor of 10, from 0.1 to 0.01.
>

I think here you mean parallel_tuple_cost.

>
> http://blog.cleverelephant.ca/2016/03/parallel-postgis-joins.html
>
> This seems non-optimal. No amount of cranking up the underlying
> function COST seems to change this, perhaps because the join cost is
> entirely based on the number of expected tuples in the join relation?
>

Is the function cost not being considered when given as join clause or you
wanted to point in general for any parallel plan it is not considered? I
think it should be considered when given as a clause for single table scan.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com