Re: SQL functions not being inlined - Mailing list pgsql-general

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@realityexists.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