On 09.04.2011 19:17, David Fetter wrote:
On Sat, Apr 09, 2011 at 03:22:14PM +0200, Jesper Krogh wrote:
This seems like a place where there is room for improvement.
2011-04-09 15:18:08.016 testdb=# select id from test1 where id< 3
order by id;
id
----
1
2
(2 rows)
Time: 0.328 ms
2011-04-09 15:18:11.936 testdb=# CREATE or Replace FUNCTION
testsort(id integer) returns integer as $$ BEGIN perform
pg_sleep(id); return id; END; $$ language plpgsql;
CREATE FUNCTION
Time: 12.349 ms
2011-04-09 15:18:22.138 testdb=# select id from test1 where id< 3
order by id,testsort(id);
id
----
1
2
(2 rows)
Time: 3001.896 ms
It seems strange that there is a need to evaluate testsort(id) at
all in this case.
How would PostgreSQL know that sorting by id leaves no ambiguity for
the next key to address?
Presumably there's a primary key constraint on id. This is one of those
cases where we could optimize, but then again, there's no reason to
write a query like that in the first place.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
