Re: AW: [HACKERS] using a btree index in order by clause?
| От | t-ishii@sra.co.jp |
|---|---|
| Тема | Re: AW: [HACKERS] using a btree index in order by clause? |
| Дата | |
| Msg-id | 199806170818.RAA10448@srapc451.sra.co.jp обсуждение исходный текст |
| Ответ на | AW: [HACKERS] using a btree index in order by clause? (Andreas Zeugswetter <andreas.zeugswetter@telecom.at>) |
| Ответы |
Re: AW: [HACKERS] using a btree index in order by clause?
|
| Список | 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@sra.co.jp
В списке pgsql-hackers по дате отправления: