>
> Still I don't understand the problem fully. min() runs very fast. What, if the fist (min-) value was deleted in some pending transaction. In this case, min() should have the same problems as max().

Getting to the next min record reads the index from left to right,
which works fine. Getting max value from a descending index is also
fast because it reads the index from left to right.
The problem is that reading from right (high end in ascending, low end
in descending) to left is not allowed.

> I think I'll give a descending index a try, since I have no sorting in my application.
>
> Are the following statements correct for a descending index which is referenced as foreign key in a second table:
>
> create table a(
>  id int not null,
>  primary key (id) using desc index ai_pk
> )
>
> create table b(
>  ref int not null
>  )
>
> alter table b add constraint bc_fk1 foreign key (ref) references a(id) on delete cascade using desc index bi_fk1
>
>
> Has a descending index any performance drawbacks when inserting rows with ascending ids ?
>

I think your syntax looks right. You may not get optimal index
density when inserting records with ascending keys into a descending
index.

I don't quite understand your complaint about round trips to get a
sequence value - you can define the field to have a default value
created by a squence/generator or just put the gen-id into the insert
and return the value. And it has the pleasant side-effect of working
under concurrent load.

Cheers,

Ann