Re: A thought on Index Organized Tables

> No, what generally happens is it fails to find a matching index entry at
> all, because the search algorithm concludes there can be no match based
> on the limited set of comparisons it's done. Transitivity failures lead
> to searching the wrong subset of the index.
>

Actually Tom, i am not able to understand that completely. But what you are
saying that in the current scenario, when there is a broken data type based
index, then it will return no results, but never will return wrong results.
So never the update will corrupt the heap data. But i take it as you say
(please, correct me, if i am wrong).
But even returning no results might lead to failures in unqiue checks. While
i inserting, i try to check whether a particular data is already inserted
and if it returns no results, then it will go ahead and insert the data
assuming that the unique check has passed, while in reality it has failed.

Wait a minute. Bingo!!!! So for unique checks we are already going to
index from Heap. So it is the same thing i am doing with Thick index. So if
we can trust our current unique checks, then we should trust the Thick
index.

Thanks Tom!!! for having this good conversation....

I think this broken data type problem / volatile function issue has to be
resolved for the current index, if we advocate to stop the thick index.
WOW!!!

Thanks,
Gokul.