Re: BUG #17560: Planner can not find plan with lowest cost

From: Francisco Olarte <folarte(at)peoplecall(dot)com>
To: stanislaw(dot)skonieczny(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17560: Planner can not find plan with lowest cost
Date: 2022-07-29 07:30:59
Message-ID: CA+bJJbwPcrhW3zgDFWqDW78gJNLdtw_xC05oBztx5s3hqfArhg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Stanislaw:

On Thu, 28 Jul 2022 at 20:57, PG Bug reporting form
<noreply(at)postgresql(dot)org> wrote:

> create table ss_temp_table1 as select id, v1, v2 from ss_d order by id desc
> limit 100000;
...
> FROM ss_d AS d
> JOIN ss_temp_table1 AS t1 ON t1.id = d.id AND t1.v1 = d.v1 AND t1.v2
> = d.v2

Do your real tables/queries have the same kind of redudant condition (
i.e., "AND t1.v1 = d.v1 AND t1.v2" is redundant due to id being a "PK"
)?

If so you could try omitting it ( and maybe try w & w/o seqscan
enabled too ) to see if this condition is leading the optimizer to
believe a plan is much cheaper than it really is.

If not you may be hitting a different problem with similar appearance.

Francisco Olarte.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2022-07-29 09:14:12 BUG #17561: Server crashes on executing row() with very long argument list
Previous Message Ajin Cherian 2022-07-29 07:05:46 Re: Excessive number of replication slots for 12->14 logical replication