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.
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 |