Re: Should duplicate indexes on same column and same tablebe allowed?

On Sat, 2006-12-09 at 12:46 -0500, Tom Lane wrote:
> "Rajesh Kumar Mallah" <mallah.rajesh@gmail.com> 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