Re: create index concurrently - duplicate index to reduce time without an index

> When you have two exactly the same index definitions, that's just a waste of resources. There will be used only one of them for speeding up selects, but all of them must be updated during insert/update/delete operations.

Thanks Szymon,

I appreciate the info. The duplication would only be for the time of the index build - which may be significant. When the new index was successfully complete we would drop the old one.

I'm concerned that just because I *can* create duplicate indexes, it doesn't mean I *should*. I'm worried it might actually break the service worse than the locking that I'm trying to avoid. Does anyone know which index will be used if there are duplicate ones and whether there is likely to be a problem?

My understanding was that the index would not be updated for inserts to the actual table - which is why one has to reindex or drop the index and create it again (with concurrently if you don't want to block reads). Am I missing something?

Perhaps I don't need to recreate the index at all - but I've been advised to reindex.

See:
http://groups.google.com/group/irod-chat/browse_thread/thread/0396d48ffecfb2b0#
"On a side note, for the irods performance, an other key factor is also
the iCAT database performances and in some of your tests below, it has
an impact. Recomputing the index on a regular basis is something
important: here, I am doing it once per week for each iCAT (cron task).
Even for a catalog with millions of files, if you have ingested tens of
thousands of new files, you will see an improvement when doing
reindexing (for example an ils performed in 0.3 s will goes down to less
than 0.1 s when reindexing has been made)."

Thanks,

Gareth