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.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
