DROP INDEX
DROP INDEX удаляет существующий индекс из базы данных. Выполнить эту команду может только владелец индекса.
Параметры
CONCURRENTLY
С этим указанием индекс удаляется, не блокируя параллельные операции выборки, добавления, изменения и удаления данных в таблице индекса. Обычный оператор DROP INDEX запрашивает исключительную блокировку для таблицы, запрещая другим обращаться к ней до завершения удаления. Если же добавлено это указание, команда, напротив, будет ждать завершения конфликтующих транзакций.
Применяя это указание, надо учитывать несколько особенностей. В частности, при этом можно задать имя только одного индекса, а параметр CASCADE не поддерживается. (Таким образом, индекс, поддерживающий ограничение UNIQUE или PRIMARY KEY, так удалить нельзя.) Кроме того, обычную команду DROP INDEX можно выполнить в блоке транзакции, а DROP INDEX CONCURRENTLY — нет. IF EXISTS
Не считать ошибкой, если индекс не существует. В этом случае будет выдано замечание. имя
Имя (возможно, дополненное схемой) индекса, подлежащего удалению. CASCADE
Автоматически удалять объекты, зависящие от данного индекса. RESTRICT
Отказать в удалении индекса, если от него зависят какие-либо объекты. Это поведение по умолчанию.
Примеры
Эта команда удалит индекс title_idx:
DROP INDEX title_idx;
Совместимость
DROP INDEX является языковым расширением PostgreSQL . Средства обеспечения индексов в стандарте SQL не описаны.
См. также
| Пред. | Начало | След. |
| DROP GROUP | Уровень выше | DROP LANGUAGE |
Как удалить индекс postgresql
DROP INDEX удаляет существующий индекс из базы данных. Выполнить эту команду может только владелец индекса.
Параметры
CONCURRENTLY
С этим указанием индекс удаляется, не блокируя одновременные операции выборки, добавления, изменения и удаления данных в таблице индекса. Обычный оператор DROP INDEX запрашивает блокировку ACCESS EXCLUSIVE для таблицы, не допуская другие обращения к ней до завершения удаления. Если же добавлено это указание, команда, напротив, будет ждать завершения конфликтующих транзакций.
Применяя это указание, надо учитывать несколько особенностей. В частности, при этом можно задать имя только одного индекса, а параметр CASCADE не поддерживается. (Таким образом, индекс, поддерживающий ограничение UNIQUE или PRIMARY KEY , так удалить нельзя.) Кроме того, обычную команду DROP INDEX можно выполнить в блоке транзакции, а DROP INDEX CONCURRENTLY — нет.
Для временных таблиц DROP INDEX всегда выполняется более простым, неблокирующим способом, так как они не могут использоваться никакими другими сеансами. IF EXISTS
Не считать ошибкой, если индекс не существует. В этом случае будет выдано замечание. имя
Имя (возможно, дополненное схемой) индекса, подлежащего удалению. CASCADE
Автоматически удалять объекты, зависящие от данного индекса, и, в свою очередь, все зависящие от них объекты (см. Раздел 5.13). RESTRICT
Отказать в удалении индекса, если от него зависят какие-либо объекты. Это поведение по умолчанию.
Примеры
Эта команда удалит индекс title_idx :
DROP INDEX title_idx;
Совместимость
DROP INDEX является языковым расширением PostgreSQL . Средства обеспечения индексов в стандарте SQL не описаны.
См. также
| Пред. | Наверх | След. |
| DROP GROUP | Начало | DROP LANGUAGE |
Операции над индексами в PostgreSQL
В этой статье рассмотрим, как создать индекс, как его удалить и переименовать, а также как произвести переиндексацию в PostgreSQL. В качестве примера возьмём опыт инженеров из подразделения PayPal — Braintree Payments.
Создаём индекс
Если вы хотите создать индекс и запустите для этого CREATE INDEX . , вы получите блокировку на всей индексируемой таблице уровня ACCESS EXCLUSIVE. А вот если вы выполните команду CREATE INDEX CONCURRENTLY . , то уровень блокировки станет всего лишь SHARE UPDATE EXCLUSIVE. При этом во втором случае будут разрешены и запись, и чтение Правда, разница в том, что вместо одного сканирования таблицы придётся выполнить 2..
На что тут стоить обратить внимание: • если несколько созданий индексов выполняются параллельно на одной таблице, они не завершат выполнение ни одного из CREATE INDEX CONCURRENTLY . , и это утверждение верно до тех пор, пока самый медленный из них всё ещё работает; • CREATE INDEX CONCURRENTLY . не сможет выполниться внутри транзакции. Вместо этого транзакциями управляет PostgreSQL, делая это неявно. В результате никакие auto-vacuum’ы не могут очистить ненужные кортежи, появившиеся после начала построения индекса и вплоть до завершения данного процесса. Если же у таблицы имеется большой объём изменений (это в особенности плохо, когда непосредственно сама таблица мала), всё это может закончиться низкой скоростью исполнения запроса; • CREATE INDEX CONCURRENTLY . завершит выполнение лишь тогда, когда завершатся все транзакции, которые используют таблицу.
Удаляем индекс
Стандартное выражение DROP INDEX . получит ACCESS EXCLUSIVE на всей PostgreSQL-таблице и на всё время удаления индекса. Если речь идёт о небольших индексах, проблем нет, и операция не занимает много времени. Но если мы говорим об огромных индексах, то работа с файловой системой займёт гораздо больше времени. Тут поможет выражение DROP INDEX CONCURRENTLY . , которое потребует блокировку уровня SHARE UPDATE EXCLUSIVE. При этом и запись, и чтение будут продолжаться до тех пор, пока осуществляется наша операция удаления индекса.
У использования DROP INDEX CONCURRENTLY . есть ряд подводных камней: • запрос нельзя использовать для удаления индекса, который поддерживал какое-нибудь ограничение (к примеру, PRIMARY KEY либо UNIQUE); • запрос нельзя использовать в качестве части транзакции, т. к. ими управляет PostgreSQL, что называется, «под капотом». В результате никакие auto-vacuum’ы не могут очистить ненужные кортежи, появившиеся после начала построения индекса и вплоть до завершения данного процесса. Опять же, если у таблицы имеется большой объём изменений (это в особенности плохо, когда непосредственно сама таблица мала), всё это может закончиться низкой скоростью исполнения запроса; • запрос завершит выполнение лишь тогда, когда завершатся все транзакции, которые используют таблицу.
Учтите, что DROP INDEX CONCURRENTLY . добавили лишь в Postgres 9.2. Если вы работаете с более ранними версиями, у вас есть возможность достичь приблизительного того же результата, если вы отметите индекс как некорректный (invalid) и к записи не готовый; потом останется сбросить буфер посредством расширения pgfincore, а уже после этого вы сможете просто удалить индекс.
Переименовываем индекс
ALTER INDEX . RENAME TO . требует блокировку на переименовываемом индексе уровня ACCESS EXCLUSIVE , то есть блокируется чтение и запись в соответствующую таблицу. Правда, существует коммит, понижающий данное требование до SHARE UPDATE EXCLUSIVE.
Производим переиндексацию
REINDEX INDEX . тоже требует ACCESS EXCLUSIVE на индексе. Дабы это исключить, рекомендуем определённый алгоритм: • создаём новый индекс, (описано выше) повторяющий существующий; • удаляем старый индекс, делая это наименее затратным способом (тоже описано выше); • переименовываем новый индекс таким образом, чтобы он повторил имя старого индекса.
Примечание: если индекс, который вы хотите перестроить, содержал ограничения, обязательно добавьте эти ограничения и в новый индекс.
PostgreSQL | Не удаляется индекс
Столкнулся с проблемой удаления одного индекса таблицы в PostgreSQL.
Индекс точно есть, его можно проверить:
SELECT * FROM pg_indexes;
Стандартная команда удаления не срабатывала и я не мог понять почему:
DROP INDEX mytabin;
Вызов этой команды выдавал ошибку:
ERROR: ОШИБКА: индекс "mytabin" не существует SQL state: 42704
Пришлось повнимательнее рассматривать официальную документацию, чтобы разглядеть в ней возможные причины ошибки.
И да. Мне удалось наткнуться на решение проблемы.
Решение проблемы удаления индекса в PostgreSQL
Индекс в PostgreSQL может не удалять по причине отсутствия схемы данных при обращении к имени самого индекса.
Это значит, что в команде DROP INDEX нужно сначала написать название схемы данных, затем поставить точку и только после точки написать имя индекса.
Ниже пример со схемой данных « scheme1 «:
DROP INDEX scheme1.mytabin;
Грустно только то, что интерфейс pgAdmin не подсказывает на возможное отсутствие написания схемы данных и приходится искать решение в сети.