!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@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[Postgresql Jobs] [Postgresql Admin] [Postgresql Performance] [Linux Clusters] [PHP Home] [PHP on Windows] [Programming PHP] [Kernel Newbies] [PHP Classes] [Find Someone Nice] [PHP Books] [PHP Databases] [Postgresql & PHP] [Yosemite]
|
|