Re: A thought on Index Organized Tables

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Karl Schnaitter <karlsch(at)gmail(dot)com>, Gokulakannan Somasundaram <gokul007(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, heikki(dot)linnakangas(at)enterprisedb(dot)com, pgsql-hackers list <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: A thought on Index Organized Tables
Date: 2010-02-24 15:52:47
Message-ID: 407d949e1002240752uc653fafia5068dd82c17f0fd@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Feb 24, 2010 at 3:12 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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.

That doesn't seem insurmountable to me. You could always allow a
REINDEX to scan the index sequentially, ignoring any index structure,
just using the tuples it finds.

However it seems to me this discussion has several only barely related
issues being covered.

1) transaction information in index

This seems like a lot of bloat in indexes. It also means breaking
a lot of other optimizations such as being able to read the tuples
directly from the heap page without locking. I'm not sure how much
those are worth though. But adding 24 bytes to every index entry seems
pretty unlikely to be a win anyways.

2) Index organized tables

This seems like a non-starter to me. We would lose the option of
doing sequential scans and the ability to have any other indexes on
the table. That would be comparable to Oracle circa 1985. We can do
better with stuff like Heikki's "grouped index tuple" and the
visibility map which don't interfere with other features as much.

3) Depending on refinding keys in the index for basic operatoin

Currently if your index procedure/operator is ill-behaved then your
index searches might fail to return matching keys. But vacuum will
work correctly and you will never have an index pointer pointing to a
dead tuple or a tuple different from the one that was originally
inserted. Things like "retail vacuum" were proposed in the past but
were rejected because the consequences of an incorrect index procedure
become much worse. You could get dangling index pointers pointing to
nonexistent tuples or even pointing to new tuples that have been
inserted into the same slot later.

I don't think these three are actually related. Afaict neither IOT nor
visibility information in indexes depend on refinding keys in the
index. But it's possible I'm missing something. Even so they're still
three separate issues.

--
greg

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2010-02-24 15:54:43 Re: [COMMITTERS] pgsql: Remove pre-7.4 documentaiton mentions, now that 8.0 is the oldest
Previous Message Kevin Grittner 2010-02-24 15:46:24 Re: A thought on Index Organized Tables