> From: Szymon Guz [mailto:mabewlun@gmail.com]
-snip-
>> 2010/6/1 <Gareth.Williams@csiro.au>
>> Hi,
>> We want to reindex the database behind a production service without interrupting the service.
>> I had an idea for creating the index with a new name then dropping the existing index and renaming the new one - and
itseems to work and would reduce the time without an index to be minimal. I tried:
psql -d ICAT -c 'create unique index concurrently tmp_idx_objt_access1
on R_OBJT_ACCESS (object_id,user_id);'
# would check if that worked before proceeding #
psql -d ICAT -c 'drop index idx_objt_access1;'
psql -d ICAT -c 'alter index tmp_idx_objt_access1 rename to idx_objt_access1;'
>> But then a colleague pointed out that maybe the name of the index is not meaningful and this might not be any use.
>> Can any experts confirm the validity of this approach or shoot it down?
> The index name is not used for planning query execution (most important thing is the index definition), but of course
itis important to have some logical name convention that usually helps in fast understanding database schema. Name the
indexas you want, database really doesn't understand the names.
Thanks Szymon,
I was afraid that was the case. So the rest of the question is, if I have two indexes with identical definitions, what
happens? I've confirmed that I can create indexes with identical definitions (except name) without postgres complaining
-and without breaking the client on my test system - but I am wary of trying it on my production system where there is
muchmore data (8GB) and I care about it's integrity so much more.
I've just tested further and if I create two indexes with identical definitions, my queries are fast, and I can delete
eitherof them and the queries are still fast, but with both deleted the queries are slow. And yes, renaming makes no
differencebut is nice for understanding the purpose of the index.
So I still haven't seen this procedure break anything, but does anyone know a reason it might be inadvisable?
Cheers,
Gareth