Re: Partition prune with stable Expr

Поиск
Список
Период
Сортировка
От Andy Fan
Тема Re: Partition prune with stable Expr
Дата
Msg-id CAKU4AWqwv=RHc-_9UFWV9rFBFAx00iqsT6BUCsiVufZsZAeHuw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Partition prune with stable Expr  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Partition prune with stable Expr
Список pgsql-hackers


On Mon, Sep 28, 2020 at 7:15 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Andy Fan <zhihui.fan1213@gmail.com> writes:
> On Mon, Sep 28, 2020 at 4:46 AM David Rowley <dgrowleyml@gmail.com> wrote:
>> Thanks for showing an interest in partition pruning. Unfortunately,
>> it's not possible to use stable functions to prune partitions during
>> planning.

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

No, that's still wrong.  The contract for a stable function is that
its result won't change over execution of a single query; but that
says *execution*, not *planning and execution*.

I have a slightly different opinion about the impact of "cached the plan
for later use will be wrong" now.  Generic plan will never be partition 
pruned plan since we don't know which partition to prune at plan time. 
So for any cached plan, it is not a  plan time partition pruned plan.  
Partition prune with stable expr is still  unacceptable even this is not
an issue but hope the snapshot issue will be the only one issue to
fix in future for this direction.   I'd like to know if I am wrong again. 

--
Best Regards
Andy Fan

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

Предыдущее
От: Dilip Kumar
Дата:
Сообщение: Re: Re: [HACKERS] Custom compression methods
Следующее
От: Christoph Berg
Дата:
Сообщение: Re: gs_group_1 crashing on 13beta2/s390x