| From: | Erik Rijkers <er(at)xs4all(dot)nl> |
|---|---|
| To: | ladayaroslav(at)yandex(dot)ru, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Cc: | PG Bug reporting form <noreply(at)postgresql(dot)org> |
| Subject: | Re: BUG #15947: Worse plan is chosen after giving the planner more freedom (partitionwise join) |
| Date: | 2019-08-10 23:54:01 |
| Message-ID: | a68a00b2971fa21bc2ee3a3f7df9d916@xs4all.nl |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2019-08-11 16:39:17 | Re: BUG #15947: Worse plan is chosen after giving the planner more freedom (partitionwise join) |
| Previous Message | PG Bug reporting form | 2019-08-10 22:28:08 | BUG #15947: Worse plan is chosen after giving the planner more freedom (partitionwise join) |