qwwqMasterZiv,
в хотелках всё хорошо
но есть хотелки другого плана: -- "REINDEX CONCURRENTLY" ещё не освоен писателями пж , а пользователи--буратинки всё за мерде бьются.
т.ч. вопрос скорее к максиму -- он же делает реиндексы в своём комперссоре. наверное -- и индексы pk и именованных констрейнтов. вопрос --как это проворачивать с минимальными локами ?
т.е. вот есть пк, и он даже, как пк, используется приложением (например лондайстом или иным читателем системников) -- и не хотелось бы его, читателя, обламывать , но и хочется к примеру его подменить быстро -- вновь созданным, компактным.
(т.е. в системных, по мере возможности, индекс помеченный как пк должен быть "всегда" (когда их читают другие), а лок должен быть как можно дешевле)
что делать ?
Никакой особо секретной магии нет.
Производится операция вида
1.
2.
3.
4.
5.
6.
CREATE INDEX CONCURRENTLY ...
BEGIN;
SET LOCAL statement_timeout TO something;
ALTER TABLE sometable DROP CONSTRAINT somename;
ALTER TABLE sometable ADD CONSTRAINT ... USING INDEX ...;
END;
Сама по себе подмена если нет мешающих транзакций фактически мнгновенная.
Далее если обломились по timeout - повторить. Если обломились N раз - ну значит не получилось на этот раз.
Т.е. некий компромисс так чтобы и локов поменьше/покороче сделать (и не уронить проект в процессе) и с максимальными шансами перестроить индекс.
Если приложение написано так что постоянно висит много открытых длинных транзакций с участием sometable - индекс перестроить не получится.
И да просто unique index подменяется без локов через create index CONCURRENTLY / drop index CONCURRENTLY, так что да местами если таблица пухнет и ее хронически приходится сжимать и при этом на ней постоянно долгие транзакции висят я заменяю на ней pk/uniq constraint на соответсвующие просто индексы. Но я знаю что я делаю, зачем и почему и использую эту возможность весьма локально.
PS: в разработке версия которая по отдельному ключу будет решать эту проблему как сделано в pg_reorg (автоматически отстреливая все мешающие транзакции), но пока это не готово.
--
Maxim Boguk
www.postgresql-consulting.ru
