Re: A thought on Index Organized Tables

On Fri, Feb 26, 2010 at 12:36 AM, Gokulakannan Somasundaram <
gokul007(at)gmail(dot)com> wrote:

> To be a bit more concrete: the typical sort of failure that you could
>> get from broken btree operators is failure of transitivity, that is
>> the comparators report A < B and B < C for some A, B, C, but do not say
>> that A < C when those two values are compared directly. I don't see any
>> convenient way to detect that as a byproduct of normal index operations,
>> because you wouldn't typically have a reason to make all three
>> comparisons in close proximity. Indeed, the searching and sorting
>> algorithms do their best to avoid making "redundant" comparisons of that
>> kind.
>>
>
> This is interesting Tom, but i am unable to understand, why it won't affect
> the current indexes. While insertion it might get inserted in a block and
> offset, and while searching it might either return no results / show a wrong
> place. Because ordering is required for searching also right? I definitely
> feel, i am missing something here.
>

It definitely affects current indexes. We can't completely avoid bad user
functions. That is why it is important to put limits on how much damage they
can do. That's the motivation for the idea I mentioned before, of
double-checking visibility data in an IndexTuple before letting it survive a
VACUUM.