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<postgresql@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
>
