Re: Partition prune with stable Expr

Поиск
Список
Период
Сортировка
От Andy Fan
Тема Re: Partition prune with stable Expr
Дата
Msg-id CAKU4AWpvKf1Kg9ZyqZyn=-jK_0Y_Tp6LMXNHTS5ONaDLy7nK5g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Partition prune with stable Expr  (David Rowley <dgrowleyml@gmail.com>)
Ответы Re: Partition prune with stable Expr
Список pgsql-hackers
Thank you David for coming:) 

On Mon, Sep 28, 2020 at 4:46 AM David Rowley <dgrowleyml@gmail.com> wrote:
On Mon, 28 Sep 2020 at 08:59, Andy Fan <zhihui.fan1213@gmail.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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Small improvements to pg_list.h's linitial(), lsecond(), lthird() etc macros
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Partition prune with stable Expr