Re: [GENERAL] query not scaling
| От | Merlin Moncure |
|---|---|
| Тема | Re: [GENERAL] query not scaling |
| Дата | |
| Msg-id | CAHyXU0y1YQTd3whJk1qcyLmbYizWPsYDpVWAq0-BrTr-Kjr0qg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [GENERAL] query not scaling (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-general |
On Thu, Oct 26, 2017 at 10:01 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Laurenz Albe <laurenz.albe@cybertec.at> 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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
В списке pgsql-general по дате отправления: