On Wed, May 19, 2004 at 15:17:01 +0200,
Atesz <[EMAIL PROTECTED]> 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.
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
