Craig Ringer writes:
> It's interesting that this variant doesn't seem to be slow:
> create or replace function to_datestamp_immutable(
> time_int double precision
> ) returns date as $$
> select date_trunc('day', timestamp 'epoch' + $1 * interval '1
> second')::date;
> $$ language sql immu
On 08/14/2013 12:17 PM, Tom Lane wrote:
> [ shrug... ] Using IMMUTABLE to lie about the mutability of a function
> (in this case, date_trunc) is a bad idea. It's likely to lead to wrong
> answers, never mind performance issues. In this particular case, I
> imagine the performance problem comes f
Craig Ringer writes:
> I've run into an interesting Stack Overflow post where the user shows
> that marking a particular function as IMMUTABLE significantly hurts the
> performance of a query.
> http://stackoverflow.com/q/18220761/398670
> CREATE OR REPLACE FUNCTION
> to_datestamp_immutable(ti
On 08/14/2013 11:52 AM, Pavel Stehule wrote:
>
> If I understand, a used IMMUTABLE flag disables inlining. What you see,
> is SQL eval overflow.
>
> My rule is - don't use flags in SQL functions, when it is possible.
Interesting. I knew that was the case for STRICT, but am surprised to
hear it's
2013/8/14 Craig Ringer
> Hi folks
>
> I've run into an interesting Stack Overflow post where the user shows
> that marking a particular function as IMMUTABLE significantly hurts the
> performance of a query.
>
> http://stackoverflow.com/q/18220761/398670
>
> CREATE OR REPLACE FUNCTION
> to_date
On 08/14/2013 08:41 AM, Craig Ringer wrote:
> Hi folks
>
> I've run into an interesting Stack Overflow post where the user shows
> that marking a particular function as IMMUTABLE significantly hurts the
> performance of a query.
Here's `perf` report data for the two.
With IMMUTABLE:
Samples: 90
