From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Rob Sargent <robjsargent(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: query not scaling |
Date: | 2017-10-27 14:56:14 |
Message-ID: | CAHyXU0y1YQTd3whJk1qcyLmbYizWPsYDpVWAq0-BrTr-Kjr0qg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, Oct 26, 2017 at 10:01 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2017-10-27 15:28:18 | Re: Announcing PostgreSQL SLES RPM Repository |
Previous Message | Weiping Qu | 2017-10-27 14:25:13 | Re: Question regarding logical replication |