Thanks, I went into that function, added log statements everywhere and
figured which check it's failing on:
!heap_attisnull(func_tuple, Anum_pg_proc_proconfig)
and it's because my real function had this at the end:
SET search_path FROM CURRENT;
which I never imagined would make any difference. This still doesn't
explain why it was being inlined sometimes - I didn't add and remove
that bit, it was there the whole time! But at least the fix is simple -
remove it.
Is there any reason this stuff isn't documented? It can have huge
performance implications, so I'm surprised more people don't run into
it. Even better would be some query that checks whether a function is
inlineable - maybe not perfectly, but it could detect a few of the
reasons just from pg_proc, right?
Regards,
Evan
On 2/05/2012 11:41 PM, Tom Lane wrote:
Evan Martin<postgre...@realityexists.net> writes:
This worked... at first. I did some simple queries and they showed the
function being inlined (index scan on primary key, seq scan - no
function scan). Very happy with that, I tried changing some other
functions (that depend on these) and then found that the _asof functions
are not being inlined anymore! I swear, I'm not making this up. Nothing
changed in those functions. Same simple query. It was inlined before and
now it's not. I've dropped and re-created the functions, did an ANALYZE,
even restarted PostgreSQL - they're not inlined any more. I really don't
know what to think!
[ squint... ] There are a lot of undocumented restrictions on inlining
in inline_set_returning_function(), but AFAICS none of them are
nondeterministic, nor would the decision depend on anything outside
the function and its arguments. Can you provide a concrete test case?
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
