Re: Best practice when reindexing in production

Поиск
Список
Период
Сортировка
От Igor Neyman
Тема Re: Best practice when reindexing in production
Дата
Msg-id A76B25F2823E954C9E45E32FA49D70EC1B7E4B37@mail.corp.perceptron.com
обсуждение исходный текст
Ответ на Re: Best practice when reindexing in production  (Matheus de Oliveira <matioli.matheus@gmail.com>)
Ответы Re: Best practice when reindexing in production
Список pgsql-performance

You could do something like this (which considers you use simple names for your indexes, where simple
~ [a-z_][a-z0-9_]*):

SELECT 
regexp_replace(i.indexdef, '^CREATE( UNIQUE)? INDEX (.*) ON (.*)', 'CREATE\1 INDEX CONCURRENTLY tmp_\2 ON \3;') ||
E'\n'
|| E'BEGIN;\n'
|| 'DROP INDEX ' || i.indexname || E';\n'
|| 'ALTER INDEX tmp_' || i.indexname || ' RENAME TO ' || i.indexname || E';\n'
|| E'COMMIT;\n'
FROM pg_indexes i
WHERE schemaname !~ '^(pg_|information_schema$)';

Although this one is *really simple* and *error phrone*, because it does not consider at least two things: index that
areconstraints and index that has FK depending on it. For the first case, you only need to change the constraint to use
theindex and the DROP command. As for the second case, you would need to remove the FKs, drop the old one and recreate
theFK (inside a transaction, of course), but this could be really slow, a reindex for this case would be simpler and
perhapsfaster. 


Regards,
-- 
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres


I must be missing something here.
But, how is that FK depends on the index?
I understand FK lookup works much faster with the index supporting FK than without it, but you could have FK without
index(on the "child" table). 
So, what gives?

Regards,
Igor Neyman


В списке pgsql-performance по дате отправления:

Предыдущее
От: Matheus de Oliveira
Дата:
Сообщение: Re: Best practice when reindexing in production
Следующее
От: Matheus de Oliveira
Дата:
Сообщение: Re: Best practice when reindexing in production