From: | t-ishii(at)sra(dot)co(dot)jp |
---|---|
To: | Andreas Zeugswetter <andreas(dot)zeugswetter(at)telecom(dot)at> |
Cc: | "'t-ishii(at)sra(dot)co(dot)jp'" <t-ishii(at)sra(dot)co(dot)jp>, "'hackers(at)postgresql(dot)org'" <hackers(at)postgreSQL(dot)org> |
Subject: | Re: AW: [HACKERS] using a btree index in order by clause? |
Date: | 1998-06-17 08:18:52 |
Message-ID: | 199806170818.RAA10448@srapc451.sra.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>> I'm wondering if we can use btree index to sort the results in a
>> certain condition. The idea is, if the order-items in the order by
>> clause have a btree index, then why we need to sort them again?
>
>Real life tests done by bruce (and I also did some on Informix) showed
>that sorting is cheaper/faster than doing the index access, if the index does not
>reduce the result set substantially.
>The index will currently already be used if the where restriction suggests it.
>This leads to presorted data.
>It would be nice if the optimizer could eliminate the sort in this case,
>even though the sort routine behaves well with presorted data,
>but here it does not actually do anything.
>
>I think the index access for order by would actually be a gain for certain cases:
>1. Interactive browsing of data (I want the first row very fast)
>2. Large result sets, that won't fit on temporary disk space.
I think these are big win too.
By the way, max(), min() would be optimized in the same way, I guess.
>The biggies also use this access method.
~~~~~~~do you mean commercial RDBMSs?
--
Tatsuo Ishii
t-ishii(at)sra(dot)co(dot)jp
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1998-06-17 10:44:34 | Re: [HACKERS] using a btree index in order by clause? |
Previous Message | Andreas Zeugswetter | 1998-06-17 07:33:43 | AW: [HACKERS] using a btree index in order by clause? |