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
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. |