From: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
---|---|
To: | "Gokulakannan Somasundaram" <gokul007(at)gmail(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Simon Riggs" <simon(at)2ndquadrant(dot)com>, <heikki(dot)linnakangas(at)enterprisedb(dot)com>, "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-24 16:28:08 |
Message-ID: | 4B84FF38020000250002F5DD@gw.wicourts.gov |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Gokulakannan Somasundaram <gokul007(at)gmail(dot)com> wrote:
>> 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.
>
> For simplicity, say we are storing all the non-leaf pages of the
> index in a seperate file, then the leaf pages are nothing but the
> table. So if we can replicate the table, then we can replicate the
> non-leaf pages (say by some modified version of reindex).
So you are essentially proposing that rather than moving the heap
data into the leaf tuples of the index in the index file, you will
move the leaf index data into the heap tuples? The pages in such a
IOT heap file would still need to look a lot like index pages, yes?
I'm not saying it's a bad idea, but I'm curious what benefits you
see to taking that approach.
-Kevin
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-02-24 16:30:50 | Re: [COMMITTERS] pgsql: Un-break pg_dump for the case of zero-column tables. |
Previous Message | Tom Lane | 2010-02-24 16:27:01 | Re: Recent vendor SSL renegotiation patches break PostgreSQL |