AW: [HACKERS] using a btree index in order by clause?

From: Andreas Zeugswetter <andreas(dot)zeugswetter(at)telecom(dot)at>
To: "'t-ishii(at)sra(dot)co(dot)jp'" <t-ishii(at)sra(dot)co(dot)jp>
Cc: "'hackers(at)postgresql(dot)org'" <hackers(at)postgresql(dot)org>
Subject: AW: [HACKERS] using a btree index in order by clause?
Date: 1998-06-17 07:33:43
Message-ID: 01BD99D3.52AA3EC0@zeugswettera.user.lan.at
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.

The biggies also use this access method.

Greetings
Andreas

Browse pgsql-hackers by date

  From Date Subject
Next Message t-ishii 1998-06-17 08:18:52 Re: AW: [HACKERS] using a btree index in order by clause?
Previous Message t-ishii 1998-06-17 02:13:11 using a btree index in order by clause?