Re: SQL functions not being inlined

Of course, it seems silly now to not have included "SET search_path FROM
current" in my post, but I had no idea what was and wasn't critical -
that was the whole problem. Wisdom begins with knowing the right
questions to ask! Yes, I was looking at the same function - even checked
SVN logs to make sure and it had that "SET" for a long time. Still have
no idea what happened there.

Re documentation - yes, the source code is well-commented, but I
wouldn't have known where to look in the code if you hadn't told me. As
a user, I didn't even know how to tell whether the function was being
inlined or not. The EXPLAIN output just said "Function scan" - but it's
/always/ said that for me, so how was I to know what it /should/ say?
What about a section under chapter 14 (Performance Tips) on functions,
which explains:

1) Why a function might run slower than running the same query directly.
(Not inlined, plan caching, other reasons?)
2) How to tell whether a function is being inlined.
3) Things that would prevent a function from being inlined. I understand
that some of these can change and ideally the doc should note which are
inherent limitations and which are current implementation restrictions.

I'm going to write this up as a blog post just for my own reference, but
nobody else is going to find it there. I'd love to see it documented
properly by someone who knows what they're talking about.

Regards,

Evan

On 4/05/2012 1:30 AM, Tom Lane wrote:
> Evan Martin<postgresql(at)realityexists(dot)net> writes:
>> 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;
> Well, shame on you for omitting that critical detail from your example.
>
>> which I never imagined would make any difference.
> The reason SET options disable inlining is that inlining would leave
> noplace for the SET to be applied and then removed. In some cases it's
> possible that we could prove that the SET need not occur at runtime,
> but the inlining mechanism doesn't have that much knowledge about
> configuration parameters.
>
>> 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!
> That does seem improbable. You sure you were looking at just one
> function?
>
>> 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.
> There are a huge number of details of planner behavior that "can have
> huge performance implications", and they change frequently. It's not
> clear to me that we can document this stuff in a way that's better than
> referring to the source code.
>
> regards, tom lane
>