Evan Martin <postgresql@xxxxxxxxxxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
