Re: Some question about lazy subquery/procedures execution in SELECT ... ORDER BY... LIMIT N queries - Mailing list pgsql-performance

From Tom Lane
Subject Re: Some question about lazy subquery/procedures execution in SELECT ... ORDER BY... LIMIT N queries
Date
Msg-id 24774.1322154302@sss.pgh.pa.us
Whole thread Raw
In response to Some question about lazy subquery/procedures execution in SELECT ... ORDER BY... LIMIT N queries  (Maxim Boguk <maxim.boguk@gmail.com>)
Responses Re: Some question about lazy subquery/procedures execution in SELECT ... ORDER BY... LIMIT N queries
List pgsql-performance
Maxim Boguk <maxim.boguk@gmail.com> writes:
> Is here any reason why Postgresql calculates subqueries/storable procedures
> in select list before applying ORDER BY / LIMIT?

Well, that's the definition of ORDER BY --- it happens after computing
the select list, according to the SQL standard.  We try to optimize this
in some cases but you can't really complain when we don't.  Consider
putting the expensive function outside the ORDER BY/LIMIT, ie

select ..., expensive_fn() from (select ... order by ... limit ...) ss;

            regards, tom lane

pgsql-performance by date:

Previous
From: Maxim Boguk
Date:
Subject: Some question about lazy subquery/procedures execution in SELECT ... ORDER BY... LIMIT N queries
Next
From: MirrorX
Date:
Subject: query uses index but takes too much time?