| From: | David Johnston <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> |
| Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Atri Sharma <atri(dot)jiit(at)gmail(dot)com> |
| Subject: | Re: Re: Patch to add functionality to specify ORDER BY in CREATE FUNCTION for SRFs |
| Date: | 2015-01-07 00:24:11 |
| Message-ID: | CAKFQuwZVz14tgSd9qBX4bqkhvSUEyGgbn3WDdGdCZQAUuaEzhQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jan 6, 2015 at 4:15 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> wrote:
> On 1/6/15, 10:32 AM, Alvaro Herrera wrote:
>
>> Tom Lane wrote:
>>
>> What would make sense to me is to teach the planner about inlining
>>> SQL functions that include ORDER BY clauses, so that the performance
>>> issue of a double sort could be avoided entirely transparently to
>>> the user.
>>>
>>
>> Wouldn't this be applicable to functions in other languages too, not
>> only SQL?
>>
>
> Dumb question... we can inline functions from other languages? What chunk
> of code handles that?
We cannot that I know of. The point being made here is that suggesting an
alternative that requires inlining doesn't cover the entire purpose of
this feature since the feature can be applied to functions that cannot be
inlined.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Josh Berkus | 2015-01-07 00:33:36 | Re: Turning recovery.conf into GUCs |
| Previous Message | Andres Freund | 2015-01-07 00:17:33 | Re: pg_rewind in contrib |