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: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers list <pgsql-hackers(at)postgresql(dot)org>, Greg Stark <gsstark(at)mit(dot)edu>, Karl Schnaitter <karlsch(at)gmail(dot)com>
Subject: Re: A thought on Index Organized Tables
Date: 2010-03-02 05:43:21
Message-ID: 9362e74e1003012143g7444bb41x64f499ca06bb68d5@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
> > a) We are already going from table to index to do unique checks. This is
> the
> > same thing, which we will do to go and update the snapshot in the
> indexes.
>
> No, it is not the same thing. Updating index snapshots requires being
> able to *re-find* a previously made index entry for the current row.
> And it has to be done 100% reliably. The worst that happens if an index
> entry is not found when it should be during a uniqueness check is that
> the uniqueness constraint is not enforced properly; which is bad but it
> doesn't lead to internally-inconsistent data structures.
>
>
Tom,
We are also going to indexes to maintain the referential integrity
constraints like foreign keys. Say there are constraints like 'On Delete
Cascade' and 'On Delete Restrict', they are maintained through the indexes
and if we say that indexes can return wrong results, then the referential
integrity is lost and we no longer are ACID compliant.

Thanks,
Gokul.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Smith 2010-03-02 05:50:08 Re: Re: Hot Standby query cancellation and Streaming Replication integration
Previous Message Bruce Momjian 2010-03-02 04:56:45 Re: Re: Hot Standby query cancellation and Streaming Replication integration