From: | Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Partition prune with stable Expr |
Date: | 2020-09-27 21:35:38 |
Message-ID: | CAKU4AWpvKf1Kg9ZyqZyn=-jK_0Y_Tp6LMXNHTS5ONaDLy7nK5g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thank you David for coming:)
On Mon, Sep 28, 2020 at 4:46 AM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> On Mon, 28 Sep 2020 at 08:59, Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com> wrote:
> > I find we can't prune partitions in the planner if the qual is a stable
> function.
>
> > IMO, we should do it. Why not?
>
> Thanks for showing an interest in partition pruning. Unfortunately,
> it's not possible to use stable functions to prune partitions during
> planning.
>
> NOW() is one example of a function that's stable, but the return value
> will change over time. If we used the return value of that to perform
> partition pruning then we'd end up with a plan that's wrong over time.
>
>
Sigh.. I understand you now, I ignored the plan can be cached for later use.
Without that, we should be able to prune with stable function. I know the
run-time partition prune can help with this, but it can't help with
planning time.
I run into some cases that SELECT * FROM p WHERE pkey = to_date(..);
p has 1500+ partitions and planning takes lots of time. and users are not
willing to remove the to_date('2018-11-11', 'yyyy-mm-dd') style code since
too much and can't find out all of them at once. Actually I think to_date
should
be marked as immuable rather than stable.
--
Best Regards
Andy Fan
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-09-27 23:15:09 | Re: Partition prune with stable Expr |
Previous Message | David Rowley | 2020-09-27 21:08:42 | Small improvements to pg_list.h's linitial(), lsecond(), lthird() etc macros |