Re: BUG #15947: Worse plan is chosen after giving the planner morefreedom (partitionwise join) - Mailing list pgsql-bugs

From Erik Rijkers
Subject Re: BUG #15947: Worse plan is chosen after giving the planner morefreedom (partitionwise join)
Date
Msg-id a68a00b2971fa21bc2ee3a3f7df9d916@xs4all.nl
Whole thread Raw
In response to BUG #15947: Worse plan is chosen after giving the planner more freedom (partitionwise join)  (PG Bug reporting form <noreply@postgresql.org>)
List pgsql-bugs
On 2019-08-11 00:28, PG Bug reporting form wrote:
> The following bug has been logged on the website:
> 
> Bug reference:      15947
> I'm trying the following query:
> 
> EXPLAIN
> SELECT COUNT(*)
>   FROM sc
>  WHERE EXISTS (
>        SELECT 1
>          FROM sg
>         WHERE sc.id = sg.sc_fk
>           AND sc.a = sg.a
>           AND sc.o = sg.o
>           AND sc.sl = sg.sl
>        );
> 
> Which produces the plan with this cost estimation (top node):
> -- Aggregate  (cost=147.25..147.26 rows=1 width=8)
> 
> But after:
> SET enable_partitionwise_join = true;
> 
> The new plan is more expensive:
> -- Aggregate  (cost=175.00..175.01 rows=1 width=8)
> 
> This shouldn't be happening, right?

Why not?

The 'worse plan' cnsistently executes faster.

I don't think the cost units of different queries can/should be compared 
as if they are the same.






















pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #15947: Worse plan is chosen after giving the planner more freedom (partitionwise join)
Next
From: Tom Lane
Date:
Subject: Re: BUG #15947: Worse plan is chosen after giving the planner more freedom (partitionwise join)