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 from having suppressed the option > to inline the function body ... but you should be more worried about > whether you aren't getting flat-out bogus answers in other cases. Oh, I totally agree, and I'd never do this myself. I was just curious about the behaviour. 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 immutable; and there's no sign it's parsed each time. So it's not just the IMMUTABLE flag. If nothing else this strongly suggests that the docs don't cover this area particularly comprehensively. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance