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