Есть ли способ показать оператор создания индекса в PostgreSQL

14

Мне нужно пересоздать индекс в PostgreSQL, который пострадал от раздувания индекса. Поскольку мне нужен индекс, чтобы его можно было использовать во время его создания, я не могу использовать REINDEX. Я собираюсь воссоздать индекс с новым именем, а затем отбросить старое. Есть ли способ увидеть оператор SQL, который использовался для создания индекса, чтобы я мог просто скопировать его?

Рори
источник
2
stackoverflow.com/questions/25958693
a_horse_with_no_name
1
Не забудьте добавить CONCURRENTLYв CREATE INDEXкоманду, чтобы не брать эксклюзивную блокировку на столе.
Крейг Рингер

Ответы:

26

На самом деле, просто запросите представление pg_indexesсистемного каталога следующим образом:

SELECT indexdef FROM pg_indexes WHERE indexname = '...'

и вы должны вернуть оператор SQL, используемый для его определения.

TomH
источник
4
Обратите внимание, что имена индексов уникальны только для каждой схемы . Вы можете добавить AND schemaname = 'myschema'.
Эрвин Брандштеттер
0

Да, полный оператор SQL для воссоздания индекса находится в системном каталоге. Самым простым способом, который я могу придумать, является использование pg_dump / pg_restore:

$ pg_dump -F c | pg_restore -I <your_index_name>
Егор Рогов
источник
4
Если база данных большая, это может быть излишним :) Возможно, вы захотите добавить, -sчтобы исключить данные и, если известно, имя таблицы с помощью -t.
Дезсо
-1

Проще говоря, если вы хотите их всех (все индексы) ...

=# SELECT indexdef FROM pg_indexes;
Мишель Салливан
источник
-1

indexdefпо-прежнему не совсем совпадает с оператором создания в случае частичного индекса. Например, если мы создаем индекс со следующим оператором: CREATE INDEX item_orgunit_idx ON items (orgunit_id) WHERE type IN ('invoice', 'purchaseorder', 'beanpayment');

Postgres сгенерирует следующий indexdef: CREATE INDEX item_orgunit_idx ON public.items USING btree (orgunit_id) WHERE ((type)::text = ANY ((ARRAY['invoice'::character varying, 'purchaseorder'::character varying, 'beanpayment'::character varying])::text[]))

Хотя postgres indexdef имеет все выведенные типы и, вероятно, лучше, наш ORM сравнивает предложение двух индексов where и думает, что они разные, когда мы генерируем сценарии миграции. Что является проблемой для нас.

Том Лей
источник
Это не отвечает на вопрос вообще.
Лоренц Альбе