Sir,
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 ?
that was one scenerio which comes to my mind for having duplicate indexes.
Regds
mallah.
On 12/9/06, Rajesh Kumar Mallah <mallah.rajesh@gmail.com> wrote:
> On 12/9/06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > "Rajesh Kumar Mallah" <mallah.rajesh@gmail.com> writes:
> > > Some of our tables have duplicate indexes on same column by different
> > > index names.
> > > Should the database server check for the existance of (effectively)
> > > same index in
> > > a table before creating a new one.
> >
> > I'd vote not; I think this would get in the way of people who do know
> > what they're doing, as much as it would hold the hands of those who
> > don't. ("Build a database that even a fool can use, and only a fool
> > would want to use it.")
> >
> > An example: suppose you mistakenly created a plain index on foo.bar,
> > when you meant it to be a unique index. You don't want to just drop the
> > plain index before creating a unique index, because you have live
> > clients querying the table and their performance would tank with no
> > index at all. But surely a plain index and a unique index on the same
> > column are redundant, so a nannyish database should prevent you from
> > creating the desired index before dropping the unwanted one.
>
> I meant *exactly* the same index (pls ignore the word effectively in prv post).
> even same tablespace.
>
> Regds
> mallah.
>
> PS: (forgive me for my meager knowledge of internals)
>
>
>
> >
> > Other scenarios: is an index on X redundant with one on X,Y? Is a hash
> > index on X redundant if there's also a btree index on X? How about
> > partial or functional indexes with slightly varying definitions?
> >
> > There's been some discussion lately about an "index advisor", which
> > might reasonably provide some advice if it thinks you have redundant
> > indexes. But I'm not eager to put any sort of enforcement of the point
> > into the core database.
> >
> > regards, tom lane
> >
>
