o tables have been permanently converted to b-tree.
Regards,
Larry G. Elkins
[EMAIL PROTECTED]
214.954.1781
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Khedr,
> Waleed
> Sent: Monday, May 06, 2002 8:13 AM
> To: Multiple recipie
y, May 06, 2002 8:13 AM
> To: Multiple recipients of list ORACLE-L
> Subject: RE: Reverse Key Index Performance
>
>
> Hi Larry,
>
> I did some testing on RKI after seeing your post. It's not any different
> that normal indexes for unique lookups.
>
> I'm sure yo
Hi Larry,
I did some testing on RKI after seeing your post. It's not any different
that normal indexes for unique lookups.
I'm sure you have some other issue like change in execution plan or even a
small difference like using/not using Oracle PQO.
Regards,
Waleed
-Original Message-
Se
>
> Sometimes it's a pity that a problem can be resolved
> without being understood, but that's the real world.
No kidding -- if some things "appear" to work, it would help to understand
the details to make sure a valid conclusion is being drawn. The test of
reverse vs. b-tree was simply performe
Larry,
|control all other factors. And I will not have the chance to do so.
As far
|as they are concerned, the production problem is resolved. So,
there's no
|need to more thoroughly investigate this -- let's move on to other
pressing
|matters. I'd like to have more details, but it's hard to jus
a frog with no legs to
jump and then writing in your journal that frogs with no legs are deaf ;-) I
don't want to be that guy ;-)
So, that's why I ask what other people have seen and about their experiences
and testing. And sorry for the length.
Regards,
Larry G. Elkins
[EMAIL PROTECTE
If this is Oracle 8.1, it is possible for the optimizer
to reject even a primary key index as too expensive
once it has been reversed. Did you check the execution
path (and I/O characteristics if necessary) to see if the
index was still being used.
I haven't been able to emulate the problem in
