Re: Some question about lazy subquery/procedures execution in SELECT ... ORDER BY... LIMIT N queries

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Maxim Boguk <maxim(dot)boguk(at)gmail(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Some question about lazy subquery/procedures execution in SELECT ... ORDER BY... LIMIT N queries
Date: 2011-11-24 17:05:02
Message-ID: 24774.1322154302@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Maxim Boguk <maxim(dot)boguk(at)gmail(dot)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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message MirrorX 2011-11-24 17:20:31 query uses index but takes too much time?
Previous Message Tom Lane 2011-11-24 03:06:10 Re: Seq Scan used instead of Index Scan