From: | Bruno Wolff III <bruno(at)wolff(dot)to> |
---|---|
To: | Atesz <atesz(at)ritek(dot)hu> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: An Index Scanning Solution question |
Date: | 2004-05-20 20:38:05 |
Message-ID: | 20040520203805.GA29319@wolff.to |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, May 19, 2004 at 15:17:01 +0200,
Atesz <atesz(at)ritek(dot)hu> wrote:
>
> I'd like to ask why the index scaning can't move on an index in
> multi-order directions (For exapmle: 1.column: forward, 2.column:
> backward and 3.column: forward again)? So I wouldn't have to use so many
> indexes. Has somebody tried to implement this idea in Postgres or is
> there a more difficult reason in the postgres implementation which
> cause this defect?
Because there is only one order on an index. So you can only go forward
and backwards over all of the columns/functions.
While it would be nice if indexes could be declared with some columns
ascending and others descending, this wouldn't solve your problem.
I would be surprized if all those combinations of indexes were really
needed. In many cases adding extra columns to an index doesn't buy
you much. Also I wouldn't expect to generate data in multiple orders
for the same set of data and that in practice the number of indexes
you need would be bounded by the number of different reports / common
queries you have.
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2004-05-20 20:49:10 | Re: commit messages from gforge -> pgsql-committers |
Previous Message | Jon Jensen | 2004-05-20 20:07:34 | Re: commit messages from gforge -> pgsql-committers |