> 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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
