Re: A thought on Index Organized Tables - Mailing list pgsql-hackers

From Gokulakannan Somasundaram
Subject Re: A thought on Index Organized Tables
Date
Msg-id 9362e74e1002261348l360e8f4dr115b17e32fd751c7@mail.gmail.com
Whole thread Raw
In response to Re: A thought on Index Organized Tables  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: A thought on Index Organized Tables
Re: A thought on Index Organized Tables
List pgsql-hackers

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.

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Hot Standby query cancellation and Streaming Replication integration
Next
From: Bruce Momjian
Date:
Subject: Re: Hot Standby query cancellation and Streaming Replication integration