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 ha
https://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=9118d03a8
Hi,
thanks!
I've just tested with 9.6 and the test runs fast with or without expensive().
So the above patch does indeed improve this case a lot!
Bye,
Chris.
--
Sent via pgsql-general mailing list (pgsql-gene
Chris Mair writes:
> From the timings it appears that in the second explain analyze query a
> function
> call in the select list (expensive()) is evaluated in the sequential scan node
> *for each* row in big, despite the use of limit.
According to the SQL standard, the SELECT list is evaluated
Chris Mair wrote:
> I've found a (simple) situation where the planner does something I don't
> understand.
>
> Below is a complete test case followed by output.
>
> From the timings it appears that in the second explain analyze query a
> function
> call in the select list (expensive()) is eval
Hi,
I've found a (simple) situation where the planner does something I don't
understand.
Below is a complete test case followed by output.
From the timings it appears that in the second explain analyze query a function
call in the select list (expensive()) is evaluated in the sequential scan n
