Winnipuh
какие команды можно применять во время работы юзеров:

1. vacuum;
2. vacuum full analyze;
3. reindex

1. не имеет смысла, если запущен autovacuum (а так сколько угодно)
2. я бы очень не рекоммендовал увлекаться FULL'ом, ибо он эксклюзивно лочит таблицу и в это время ни чтение, ни запись другим пользователям будет не доступно.
3. Полезно. Только учтите, что SELECT'ы, где используется этот индекс будут ждать пока ваш реиндекс не пройдет. Поэтому в некоторых случаях эффективнее сделать DROP/CREATE индексу.

4321
REINDEX is similar to a drop and recreate of the index in that the index contents are rebuilt from scratch. However, the locking considerations are rather different. REINDEX locks out writes but not reads of the index's parent table. It also takes an exclusive lock on the specific index being processed, which will block reads that attempt to use that index.

In contrast, DROP INDEX momentarily takes exclusive lock on the parent table, blocking both writes and reads. The subsequent CREATE INDEX locks out writes but not reads; since the index is not there, no read will attempt to use it, meaning that there will be no blocking but reads may be forced into expensive sequential scans. Another important point is that the drop/create approach invalidates any cached query plans that use the index, while REINDEX does not.

т.е. совет сомнителен. А вот хп-ки могут начать ругаться на отсутствие рилейшена оид такой-то (до переконнекта).

Вы выделили красным не то место. Вот так лучше:
It also takes an exclusive lock on the specific index being processed, which will block reads that attempt to use that index.

А в чем совет сомнителен? Вы не советуете делать REINDEX?

4321гм. я, кстати сказать, выделил самое то. Таблица не лочица, но не используется индекс. Чем это отличается от дропа?
Конечно, если вы знаете способ заюзать индекс после дропа, но до завершения криейта - другое дело.

Ну во первых, я нигде не агитировал использовать DROP/CREATE вместо REINDEX. Я сказал, что бывают случаи когда DROP/CREATE может заменить REINDEX.
А во вторых, отличие в том, что когда происходит REINDEX вашего 10 гигабайтного индекса, то все операции, которым оптимайзер "прописал" этот индекс будут ждать окончания REINDEX'а (включая SELECT'ы).

4321
а сомнителен - т.к. при работающих клиентах желательно избегать пользовать DROP/RESTORE - в силу
авторAnother important point is that the drop/create approach invalidates any cached query plans that use the index, while REINDEX does not. , что приводит к проблемам у работающих юзеров (надо перегружать хп-ки).
С другой стороны разницы промеж локами на таблицу промеж REINDEX и DROP/RESTORE в хелпе сильной не наблюдается.
Ну произойдет новый hard parse и создастся новый план выполнения. Конечно это не очень хорошо для производительности... но такой вариант имеет место быть.

P.s.
Сам стараюсь обходиться REINDEX'ами... :)