Re: BUG #17650: For the sixth time, the clipping function in the 120 partition table planning stage fails

From: Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: dafoer_x(at)163(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17650: For the sixth time, the clipping function in the 120 partition table planning stage fails
Date: 2022-10-19 02:21:42
Message-ID: CAKU4AWpkOiDYO=3YYwS_gsH0-txOj8j=ST9akmdJSAoDuftUUg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Tue, Oct 18, 2022 at 10:06 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Then it'll decide "nope, we'll stick to custom
> planning" and the subsequent executions take the same amount of
> time as before.
>

I think we have known the cost model issue for any kind of run-time
partition prune
(initial partition prune or execution partition prune), the issue is that
we always cost
the partitions which have been pruned already. One of the side effects is
that a generic
plan is nearly impossible to win, hence planning effort is always there.
Do you think
we need to do anything for this? We can't forecast how many /
which partitions
are pruned or left, but even we just improve the case where only 1
partition is left, we
improve the most common cases.

--
Best Regards
Andy Fan

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Amit Kapila 2022-10-19 09:46:59 Re: WAL segments removed from primary despite the fact that logical replication slot needs it.
Previous Message Kyotaro Horiguchi 2022-10-19 02:00:32 Re: WAL segments removed from primary despite the fact that logical replication slot needs it.