Re: expensive function in select list vs limit clause

From: Chris Mair <chris(at)1006(dot)org>
To: Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: expensive function in select list vs limit clause
Date: 2017-04-05 15:23:13
Message-ID: 792ac2c7283e3efab818aba9ca063416@smtp.hushmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


>
> ORDER BY can only be processed after all rows have been fetched, this
> includes the expensive result column.
>
> You can easily avoid that by applying the LIMIT first:
>
> SELECT r, expensive()
> FROM (SELECT r
> FROM big
> ORDER BY r
> LIMIT 10
> ) inner;
>
> I don't know how hard it would be to only fetch the necessary columns before
> the ORDER BY and fetch the others after the LIMIT has been applied, but it
> is probably nontrivial and would require processing time for *everybody*
> who runs a query with ORDER BY to solve a rare problem that can easily be
> worked around.

Hi,

Tom Lane just pointed out that 9.6 is able to optimise this (at least
the synthetic example).

Anyway, my real problem could be beautifully improved by subselect-trick!

Thanks a lot!

Bye,
Chris.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2017-04-05 16:16:42 Re: Advise on primary key for detail tables (OS: Raspberry Pi)
Previous Message Chris Mair 2017-04-05 15:20:20 Re: expensive function in select list vs limit clause