Re: BUG #10194: Stable function in select clause cann't be optimized to one call?

From: 德哥 <digoal(at)126(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #10194: Stable function in select clause cann't be optimized to one call?
Date: 2014-05-02 00:13:49
Message-ID: 76b7e55f.4fb0.145ba47aa11.Coremail.digoal@126.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

HI, >Because its value might change between planning and execution.When in seqscan mode, stable function not be optimized to one-call .
But in index-scan mode, it's in one-call mode.
If its value might change between planning and execution. I think stable function also not allowed used in index scan mode.

--
公益是一辈子的事,I'm Digoal,Just Do It.

At 2014-05-02 03:37:16,"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>digoal(at)126(dot)com writes:
>> Why stable function in select clause cann't optimized to one time call?
>
>Because its value might change between planning and execution.
>
>There was some discussion awhile back of performing run-time caching of
>the result, but it isn't done yet, and would impose some costs of its own.
>
>BTW, this sort of question is not a bug.
>
> regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Nick Rupley 2014-05-02 15:42:41 Re: BUG #10189: Limit in 9.3.4 no longer works when ordering using a composite multi-type index
Previous Message Tom Lane 2014-05-01 19:37:16 Re: BUG #10194: Stable function in select clause cann't be optimized to one call?