Re: Re: Patch to add functionality to specify ORDER BY in CREATE FUNCTION for SRFs

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Atri Sharma <atri(dot)jiit(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: David G Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: Patch to add functionality to specify ORDER BY in CREATE FUNCTION for SRFs
Date: 2015-01-05 20:59:43
Message-ID: 54AAFB3F.9080509@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 1/5/15, 12:20 PM, Atri Sharma 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.
>
>
> It sounds good, but inlining in current way shall restrict the scope of optimization (which is not applicable for current design). For eg, you cannot inline RECORD returning SRFs...

Related... I'd like to see a way to inline a function that does something like:

CREATE FUNCTION foo(text) RETURNS int LANGUAGE sql AS $$
SELECT a FROM b WHERE lower(b.c) = lower($1)
$$

and have the performance be comparable to

SELECT ..., (SELECT a FROM b WHERE lower(b.c) = lower(something)) AS foo

I realize that there's a whole question about the function not being an SRF, but the thing is this works great when manually inlined and is fast. The SQL function is significantly slower.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-01-05 21:14:56 Re: Re: Patch to add functionality to specify ORDER BY in CREATE FUNCTION for SRFs
Previous Message Peter Eisentraut 2015-01-05 20:56:16 Re: SSL information view