Skip site navigation (1) Skip section navigation (2)

Re: A thought on Index Organized Tables

From: Gokulakannan Somasundaram <gokul007(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Karl Schnaitter <karlsch(at)gmail(dot)com>, pgsql-hackers list <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: A thought on Index Organized Tables
Date: 2010-02-26 21:48:42
Message-ID: 9362e74e1002261348l360e8f4dr115b17e32fd751c7@mail.gmail.com (view raw or flat)
Thread:
Lists: 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.

In response to

Responses

pgsql-hackers by date

Next:From: Dimitri FontaineDate: 2010-02-26 22:11:28
Subject: Re: Hot Standby query cancellation and Streaming Replication integration
Previous:From: Bruce MomjianDate: 2010-02-26 21:48:38
Subject: Re: Hot Standby query cancellation and Streaming Replication integration

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group