From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | David Fetter <david(at)fetter(dot)org> |
Cc: | Jesper Krogh <jesper(at)krogh(dot)cc>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Evaluation of secondary sort key. |
Date: | 2011-04-09 16:24:15 |
Message-ID: | 4DA0882F.1000406@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-04-09 16:54:09 | Re: Evaluation of secondary sort key. |
Previous Message | Jesper Krogh | 2011-04-09 16:23:25 | Re: Evaluation of secondary sort key. |