> When you have two exactly the same index definitions, that's just a waste of resources. There will be used only
oneof 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
thenew 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
actuallybreak the service worse than the locking that I'm trying to avoid. Does anyone know which index will be used if
thereare 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
reindexor 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
