| 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: | Whole Thread | Raw Message | 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.
| 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 |