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

From Tom Lane
Subject Re: A thought on Index Organized Tables
Date
Msg-id 6884.1267024323@sss.pgh.pa.us
Whole thread Raw
In response to Re: A thought on Index Organized Tables  (Karl Schnaitter <karlsch@gmail.com>)
Responses Re: A thought on Index Organized Tables
Re: A thought on Index Organized Tables
Re: A thought on Index Organized Tables
List pgsql-hackers
Karl Schnaitter <karlsch@gmail.com> writes:
> On Wed, Feb 24, 2010 at 12:53 AM, Gokulakannan Somasundaram <
> gokul007@gmail.com> wrote:
>> Again not to deviate from my initial question, can we make a decision
>> regarding unstable/mutable functions / broken data types ?
>> 
> I second this question. A year or two ago, Gokul and I both proposed a
> feature that put visibility metadata into the index tuples and supported
> index-only scans, and the idea was dismissed because a user might choose
> incorrect ordering operators. I tried to ask for a clear explanation of the
> issue, but never got it.

The fundamental point IMHO is that indexes are more complex and much
more fragile than heaps.  This is obviously true theoretically and we
have years of experience that proves it to be true in the field as well.
Broken comparison functions are just one of the possible hazards; there
are many others.

Now with standard indexes you can always recover from any problem via
REINDEX; no matter how badly the index is messed up, your data is still
there and not damaged.  (Well, maybe it will fail a unique constraint
check or something, but at least it's still there.)

With an IOT I don't understand how you get out of index corruption
without data loss.  That's a showstopper for practical use, I think.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: A thought on Index Organized Tables
Next
From: Bruce Momjian
Date:
Subject: Re: [COMMITTERS] pgsql: Un-break pg_dump for the case of zero-column tables.