On Sat, 2006-12-09 at 12:46 -0500, Tom Lane wrote:
> "Rajesh Kumar Mallah" <mallah.rajesh@xxxxxxxxx> writes:
> > Suppose an index get corrupted. And you need create a new index
> > with exact specs and then drop the old index. Is it better to
> > have a performing corrupted index or not have it at all and temporarily
> > suffer some performance degradation ?
>
> The case that was being discussed just a day or two ago was where you
> wanted to do the equivalent of REINDEX because of index bloat, not any
> functional "corruption". In that case it's perfectly clear that
> temporarily not having the index isn't acceptable ... especially if
> it's enforcing a unique constraint.
I can see that is quite handy.
However, I can't see any benefit to allowing multiple FKs:
postgres=# alter table accounts add foreign key (bid) references
branches;
ALTER TABLE
Time: 1678.240 ms
postgres=# alter table accounts add foreign key (bid) references
branches;
ALTER TABLE
Time: 909.706 ms
postgres=# alter table accounts add foreign key (bid) references
branches;
ALTER TABLE
Time: 507.673 ms
postgres=# alter table accounts add foreign key (bid) references
branches;
ALTER TABLE
Time: 597.909 ms
postgres=# alter table accounts add foreign key (bid) references
branches;
ALTER TABLE
Time: 677.125 ms
postgres=# \d accounts
Table "public.accounts"
Column | Type | Modifiers
----------+---------+-----------
aid | integer | not null
bid | integer |
abalance | integer |
Indexes:
"accounts_pkey" PRIMARY KEY, btree (aid)
Foreign-key constraints:
"accounts_bid_fkey" FOREIGN KEY (bid) REFERENCES branches(bid)
"accounts_bid_fkey1" FOREIGN KEY (bid) REFERENCES branches(bid)
"accounts_bid_fkey2" FOREIGN KEY (bid) REFERENCES branches(bid)
"accounts_bid_fkey3" FOREIGN KEY (bid) REFERENCES branches(bid)
"accounts_bid_fkey4" FOREIGN KEY (bid) REFERENCES branches(bid)
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
