On Thu, Oct 26, 2017 at 10:01 AM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > Laurenz Albe <laurenz.albe@xxxxxxxxxxx> writes: >> Also, to have PostgreSQL inline the function, which would be good >> for performance, it should be declared IMMUTABLE. > > Actually, if you hope to have a SQL function be inlined, it's better > not to decorate it at all --- not with IMMUTABLE, and not with STRICT > either. Both of those restrict the parser's ability to inline unless > it can prove the contained expression is equally immutable/strict. > With the default attributes of volatile/not strict, there's nothing > to prove. This is extremely obnoxious. Is it possible to raise a warning on function creation? > (In any case, it's usually easy enough to tell from EXPLAIN output > whether inlining has happened.) No it isn't. The explain syntax is arcane and inlining as a general concept is only very indirectly expressed. I really think we ought to do better here; I was not able to find any treatment of inlining given in the 'Performance Tips' or the 'Functions and Operators' section, or anywhere really (except the wiki). This is really a disservice to the users, I think. merlin -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
