CREATE INDEX#

CREATE INDEX
CREATE INDEX
Назад НаверхSQL КомандыНачало Далее

CREATE INDEX

CREATE INDEX — определить новый индекс

Синтаксис

CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] [ [ IF NOT EXISTS ] name ] ON [ ONLY ] table_name [ USING method ]
    ( { column_name | ( expression ) } [ COLLATE collation ] [ opclass [ ( opclass_parameter = value [, ... ] ) ] ] [ ASC | DESC ] [ NULLS { FIRST | LAST } ] [, ...] )
    [ INCLUDE ( column_name [, ...] ) ]
    [ NULLS [ NOT ] DISTINCT ]
    [ WITH ( storage_parameter [= value] [, ... ] ) ]
    [ TABLESPACE tablespace_name ]
    [ WHERE predicate ]

Описание

CREATE INDEX создает индекс на указанных столбцах указанного отношения, которое может быть таблицей или материализованным представлением. Индексы в основном используются для повышения производительности базы данных (хотя неправильное использование может привести к замедлению производительности).

Ключевое поле(поля) для индекса указывается в виде имен столбцов, или альтернативно в виде выражений, записанных в скобках. Если метод индексации поддерживает многоколоночные индексы, можно указать несколько полей.

Поле индекса может быть выражением, вычисляемым из значений одного или нескольких столбцов строки таблицы. Эта функция может быть использована для быстрого доступа к данным на основе некоторого преобразования базовых данных. Например, индекс, вычисленный на основе upper(col), позволит использовать индекс для предложения WHERE upper(col) = 'JIM'.

Tantor SE предоставляет методы индексации B-дерево, хеш, GiST, SP-GiST, GIN и BRIN. Пользователи также могут определить свои собственные методы индексации, но это довольно сложно.

Когда присутствует предложение WHERE, создается частичный индекс. Частичный индекс - это индекс, который содержит записи только для части таблицы, обычно для части, которая более полезна для индексирования, чем остальная часть таблицы. Например, если у вас есть таблица, которая содержит как оплаченные, так и неоплаченные заказы, где неоплаченные заказы занимают небольшую долю от общей таблицы, и при этом это часто используемый раздел, вы можете улучшить производительность, создав индекс только для этой части. Еще одно возможное применение - использование WHERE с UNIQUE для обеспечения уникальности в подмножестве таблицы. См. Раздел 11.8 для более подробного обсуждения.

В выражении, используемом в предложении WHERE, можно ссылаться только на столбцы базовой таблицы, но можно использовать все столбцы, а не только те, которые индексируются. В настоящее время подзапросы и агрегатные выражения также запрещены в WHERE. Те же ограничения применяются к полям индекса, которые являются выражениями.

Все функции и операторы, используемые в определении индекса, должны быть “неизменяемыми”, то есть их результаты должны зависеть только от их аргументов и никогда не зависеть от внешнего влияния (такого как содержимое другой таблицы или текущее время). Это ограничение гарантирует, что поведение индекса определено однозначно. Чтобы использовать пользовательскую функцию в выражении индекса или предложения WHERE, необходимо пометить функцию как неизменяемую при ее создании.

Параметры

UNIQUE

При создании индекса (если данные уже существуют) и каждый раз при добавлении данных, это приводит к проверке системой на наличие дублирующих значений в таблице. Попытки вставить или обновить данные, которые приведут к дублированию записей, вызовут ошибку.

Дополнительные ограничения применяются, когда уникальные индексы применяются к разделенным таблицам; см. CREATE TABLE.

CONCURRENTLY

Когда используется эта опция, Tantor SE будет строить индекс без блокировки, которая предотвращает одновременные вставки, обновления или удаления в таблице; в то время как стандартное создание индекса блокирует записи (но не чтение) в таблице до его завершения. Существует несколько оговорок, о которых следует знать при использовании этой опции - см. Building Indexes Concurrently ниже.

Для временных таблиц CREATE INDEX всегда является непараллельной операцией, так как другая сессия не может к ним обращаться, и непараллельное создание индекса является более дешевым.

IF NOT EXISTS

Не генерировать ошибку, если уже существует отношение с таким же именем. В этом случае будет выдано уведомление. Обратите внимание, что не гарантируется, что существующий индекс будет похож на тот, который был бы создан. Имя индекса требуется, когда указана опция IF NOT EXISTS.

INCLUDE

Опциональное предложение INCLUDE позволяет указать список столбцов, которые будут включены в индекс в качестве неключевых столбцов. Неключевой столбец не может использоваться в качестве условия поиска при сканировании индекса и не учитывается при проверке уникальности или исключения, обеспечиваемых индексом. Однако, при сканировании только индекса можно получить содержимое неключевых столбцов без необходимости посещения таблицы, так как они доступны непосредственно из записи индекса. Таким образом, добавление неключевых столбцов позволяет использовать сканирование только индекса для запросов, которые иначе не могли бы его использовать.

Следует быть осторожным при добавлении не ключевых столбцов в индекс, особенно если они широкие. Если кортеж индекса превышает максимально допустимый размер для данного типа индекса, вставка данных завершится неудачей. В любом случае, не ключевые столбцы дублируют данные из таблицы индекса и увеличивают размер индекса, что может замедлить поиск. Кроме того, дедупликация B-дерева никогда не используется с индексами, имеющими не ключевой столбец.

Все столбцы, перечисленные в предложении INCLUDE, не требуют соответствующих классов операторов; предложение может включать столбцы, типы данных которых не имеют определенных классов операторов для заданного метода доступа.

Выражения не поддерживаются в качестве включенных столбцов, так как они не могут использоваться в индексированных сканированиях.

В настоящее время методы доступа к индексам B-tree, GiST и SP-GiST поддерживают эту функцию. В этих индексах значения столбцов, перечисленных в предложении INCLUDE, включаются в листовые кортежи, которые соответствуют кортежам кучи, но не включаются в верхнеуровневые записи индекса, используемые для навигации по дереву.

name

Имя индекса, который будет создан. Здесь не может быть указано имя схемы; индекс всегда создается в той же схеме, что и его родительская таблица. Имя индекса должно отличаться от имени любого другого отношения (таблицы, последовательности, индекса, представления, материализованного представления или внешней таблицы) в этой схеме. Если имя не указано, Tantor SE выбирает подходящее имя на основе имени родительской таблицы и имен(и) индексируемого столбца(ов).

ONLY

Указывает, не рекурсивно создавать индексы на разделах, если таблица разделена. По умолчанию рекурсия включена.

table_name

Имя (возможно, с указанием схемы) таблицы, которую необходимо проиндексировать.

method

Выбор метода индексации, который будет использоваться. Варианты: btree, hash, gist, spgist, gin, brin или установленные пользователем методы доступа, такие как bloom. Метод по умолчанию - btree.

column_name

Имя столбца таблицы.

expression

Выражение, основанное на одном или нескольких столбцах таблицы. Обычно выражение должно быть записано с окружающими скобками, как показано в синтаксисе. Однако скобки могут быть не указаны, если выражение имеет форму вызова функции.

collation

Имя правила сортировки, которое следует использовать для индекса. По умолчанию индекс использует правила сортировки, объявленное для столбца, который будет индексироваться, или итоговое правило сортировки выражения, которое будет индексироваться. Индексы с кастомными правилами сортировки могут быть полезны для запросов, в которых используются выражения с кастомными правилами сортировки.

opclass

Имя класса оператора. См. ниже для получения более подробной информации.

opclass_parameter

Имя параметра класса оператора. См. ниже для получения более подробной информации.

ASC

Указывает порядок сортировки по возрастанию (который является значением по умолчанию).

DESC

Указывает порядок сортировки по убыванию.

NULLS FIRST

Указывает, что значения NULL сортируются перед ненулевыми значениями. Это значение по умолчанию, когда указано DESC.

NULLS LAST

Указывает, что значения NULL сортируются после ненулевых значений. Это значение по умолчанию, когда не указано DESC.

NULLS DISTINCT
NULLS NOT DISTINCT

Определяет, должны ли для уникального индекса значения null считаться различными (не равными). По умолчанию они считаются различными, так что уникальный индекс может содержать несколько значений null в столбце.

storage_parameter

Имя параметра хранения, специфичного для метода индекса. См. ниже Index Storage Parameters для получения подробной информации.

tablespace_name

Указывает табличное пространство, в котором будет создан индекс. Если не указано, будет использовано значение параметра default_tablespace, или temp_tablespaces для индексов на временных таблицах.

predicate

Выражение ограничения для частичного индекса.

Параметры хранения индексов

Необязательное предложение WITH определяет параметры хранения для индекса. Каждый метод индексации имеет свой набор допустимых параметров хранения. Методы индексации B-дерева, хеша, GiST и SP-GiST все принимают этот параметр:

fillfactor (integer)

Заполнитель для индекса - это процент, который определяет, насколько полными будут заполняться страницы индекса. Для B-деревьев листовые страницы заполняются до этого процента во время начального построения индекса, а также при расширении индекса справа (добавлении новых наибольших значений ключей). Если страницы впоследствии становятся полностью заполненными, они будут разделены, что приводит к фрагментации структуры индекса на диске. B-деревья используют заполнитель по умолчанию равный 90, но можно выбрать любое целое значение от 10 до 100.

B-деревянные индексы на таблицах, где ожидается много вставок и/или обновлений, могут получить выгоду от более низких значений fillfactor во время CREATE INDEX (после массовой загрузки в таблицу). Значения в диапазоне от 50 до 90 могут полезно “сгладить” скорость разделения страниц в начальной стадии жизни B-деревянного индекса (уменьшение fillfactor таким образом может даже уменьшить абсолютное количество разделений страниц, хотя этот эффект сильно зависит от рабочей нагрузки). Техника удаления B-деревянного индекса снизу вверх, описанная в Раздел 65.4.2, зависит от наличия некоторого “дополнительного” пространства на страницах для хранения “дополнительных” версий кортежей, поэтому fillfactor может влиять на это (хотя эффект обычно незначителен).

В некоторых конкретных случаях может быть полезно увеличить fillfactor до 100 во время CREATE INDEX для максимального использования пространства. Вы должны рассмотреть это только в том случае, если вы абсолютно уверены, что таблица является статической (т.е. она никогда не будет затронута вставками или обновлениями). В противном случае, установка fillfactor в 100 может негативно сказаться на производительности: даже несколько обновлений или вставок вызовут внезапное разделение страниц.

Другие методы индексации используют fillfactor по-разному, но примерно аналогичным образом; значение fillfactor по умолчанию различается в зависимости от метода.

B-деревянные индексы дополнительно принимают этот параметр:

deduplicate_items (boolean)

Управляет использованием техники дедупликации B-дерева, описанной в Раздел 65.4.3. Установите значение ON или OFF, чтобы включить или отключить оптимизацию. (Допускаются альтернативные написания ON и OFF, как описано в Раздел 19.1). По умолчанию установлено значение ON.

Примечание

Отключение deduplicate_items с помощью ALTER INDEX предотвращает будущие вставки, вызывающие дедупликацию, но само по себе не делает существующие кортежи списка публикаций использовать стандартное представление кортежа.

GiST индексы дополнительно принимают этот параметр:

buffering (enum)

Определяет, используется ли буферизованная техника построения индекса, описанная в Раздел 66.4.1. При значении OFF буферизация отключена, при значении ON она включена, а при значении AUTO она изначально отключена, но включается по мере увеличения размера индекса до значения effective_cache_size. По умолчанию используется значение AUTO. Обратите внимание, что если возможно использование сортированного построения, оно будет использоваться вместо буферизованного построения, если не указано значение buffering=ON.

GIN-индексы принимают различные параметры:

fastupdate (boolean)

Этот параметр управляет использованием быстрой техники обновления, описанной в Раздел 68.4.1. Он является логическим параметром: ON включает быстрое обновление, OFF отключает его. По умолчанию установлено значение ON.

Примечание

Отключение fastupdate с помощью ALTER INDEX предотвращает будущие вставки в список ожидающих записей индекса, но само по себе не сбрасывает предыдущие записи. Возможно, вам захочется выполнить VACUUM для таблицы или вызвать функцию gin_clean_pending_list после этого, чтобы убедиться, что список ожидающих записей пуст.

gin_pending_list_limit (integer)

Пользовательский параметр gin_pending_list_limit. Это значение указывается в килобайтах.

BRIN индексы принимают различные параметры:

pages_per_range (integer)

Определяет количество блоков таблицы, составляющих один блочный диапазон для каждой записи индекса BRIN (см. Раздел 69.1 для получения дополнительной информации). По умолчанию установлено значение 128.

autosummarize (boolean)

Определяет, стоит ли запланировать выполнение суммирования для предыдущего диапазона страниц, когда обнаруживается вставка на следующей странице. См. Раздел 69.1.1 для получения дополнительной информации. По умолчанию установлено значение off.

Создание индексов параллельно

Создание индекса может помешать нормальной работе базы данных. Обычно Tantor SE блокирует таблицу, которую нужно проиндексировать, от записи и выполняет построение индекса с помощью одного прохода по таблице. Другие транзакции все еще могут читать таблицу, но если они попытаются вставить, обновить или удалить строки в таблице, они будут заблокированы до завершения построения индекса. Это может серьезно повлиять на работу системы, если она является живой производственной базой данных. Очень большие таблицы могут занимать много часов для индексации, и даже для меньших таблиц построение индекса может блокировать запись на такие длительные периоды, которые неприемлемы для производственной системы.

Tantor SE поддерживает создание индексов без блокировки записей. Этот метод вызывается с помощью опции CONCURRENTLY команды CREATE INDEX. При использовании этой опции Tantor SE должен выполнить два сканирования таблицы и дождаться завершения всех существующих транзакций, которые могут потенциально изменять или использовать индекс. Таким образом, этот метод требует больше работы, чем обычное создание индекса, и занимает значительно больше времени для завершения. Однако, поскольку он позволяет продолжать нормальные операции во время создания индекса, этот метод полезен для добавления новых индексов в производственной среде. Конечно, дополнительная нагрузка на ЦП и ввод-вывод, вызванная созданием индекса, может замедлить другие операции.

Во время параллельного построения индекса, индекс фактически вводится в системные каталоги как недействительный индекс в одной транзакции, затем два сканирования таблицы выполняются в двух других транзакциях. Перед каждым сканированием таблицы, построение индекса должно ждать завершения существующих транзакций, которые изменяли таблицу. После второго сканирования, построение индекса должно ждать завершения любых транзакций, которые имеют снимок (см. Глава 13) предшествующий второму сканированию, включая транзакции, используемые любой фазой параллельного построения индекса на других таблицах, если индексы, участвующие, являются частичными или имеют столбцы, которые не являются простыми ссылками на столбцы. Затем, наконец, индекс может быть помечен как действительный и готов к использованию, и команда CREATE INDEX завершается. Однако, даже после этого, индекс может не быть немедленно доступным для запросов: в худшем случае, он не может быть использован до тех пор, пока существуют транзакции, предшествующие началу построения индекса.

Если возникает проблема при сканировании таблицы, такая как блокировка или нарушение уникальности в уникальном индексе, команда CREATE INDEX завершится неудачей, но оставит “недействительный” индекс. Этот индекс будет игнорироваться при выполнении запросов, так как он может быть неполным; однако он все равно будет потреблять дополнительные ресурсы на обновление. Команда \d psql будет отображать такой индекс как INVALID. 

postgres=# \d tab
       Table "public.tab"
 Column |  Type   | Collation | Nullable | Default
--------+---------+-----------+----------+---------
 col    | integer |           |          |
Indexes:
    "idx" btree (col) INVALID

Рекомендуемый метод восстановления в таких случаях - удалить индекс и попробовать снова выполнить CREATE INDEX CONCURRENTLY. (Другая возможность - перестроить индекс с помощью REINDEX INDEX CONCURRENTLY).

Следует помнить, что при одновременном создании уникального индекса существует еще одно ограничение: уникальность уже проверяется для других транзакций, когда начинается второе сканирование таблицы. Это означает, что нарушения ограничения могут быть сообщены в других запросах до того, как индекс станет доступным для использования, или даже в случае, если создание индекса в конечном итоге завершится неудачей. Кроме того, если во время второго сканирования происходит сбой, индекс остается "недействительным" и продолжает применять свое ограничение уникальности.

Поддерживаются параллельные сборки индексов выражений и частичных индексов. Ошибки, возникающие при вычислении этих выражений, могут вызвать поведение, аналогичное описанному выше для нарушений уникального ограничения.

Во время обычной сборки индекса другие обычные сборки индекса на той же таблице могут происходить одновременно, но только одна параллельная сборка индекса может происходить на таблице одновременно. В обоих случаях изменение схемы таблицы не разрешено во время построения индекса. Еще одно отличие заключается в том, что обычная команда CREATE INDEX может выполняться внутри блока транзакции, но CREATE INDEX CONCURRENTLY - нет.

Параллельная сборка индексов для разделенных таблиц в настоящее время не поддерживается. Однако вы можете параллельно строить индекс на каждом отдельном разделе, а затем, в конечном итоге, создать разделенный индекс без параллельности, чтобы сократить время блокировки записей в разделенной таблице. В этом случае сборка разделенного индекса является только операцией с метаданными.

Примечания

См. Глава 11 для получения информации о том, когда можно использовать индексы, когда они не используются и в каких конкретных ситуациях они могут быть полезными.

В настоящее время только методы индексации B-tree, GiST, GIN и BRIN поддерживают индексы с несколькими ключевыми столбцами. Возможность использования нескольких ключевых столбцов не зависит от того, можно ли добавлять столбцы INCLUDE в индекс. Индексы могут содержать до 32 столбцов, включая столбцы INCLUDE. (Этот предел можно изменить при построении Tantor SE). Только B-tree в настоящее время поддерживает уникальные индексы.

Для каждого столбца индекса можно указать класс операторов с необязательными параметрами. Класс операторов определяет операторы, которые будут использоваться индексом для данного столбца. Например, индекс B-дерева на четырехбайтовых целых числах будет использовать класс int4_ops; этот класс операторов включает функции сравнения для четырехбайтовых целых чисел. На практике класс операторов по умолчанию для типа данных столбца обычно достаточен. Основная цель наличия классов операторов заключается в том, что для некоторых типов данных может существовать более одного значимого порядка. Например, мы можем хотеть отсортировать данные типа комплексное число либо по абсолютному значению, либо по действительной части. Мы можем сделать это, определив два класса операторов для данного типа данных, а затем выбрав соответствующий класс при создании индекса. Более подробную информацию о классах операторов можно найти в разделе Раздел 11.10 и в разделе Раздел 36.15.

Когда CREATE INDEX вызывается для разделенной таблицы, поведение по умолчанию состоит в рекурсивном обходе всех секций, чтобы убедиться, что у них есть соответствующие индексы. Сначала проверяется каждый раздел, чтобы определить, существует ли уже эквивалентный индекс, и если да, этот индекс будет присоединен в качестве индекса секции к создаваемому индексу, который станет его родительским индексом. Если соответствующий индекс не существует, будет создан новый индекс и автоматически присоединен; имя нового индекса в каждом разделе будет определено так, как если бы в команде не было указано имя индекса. Если указана опция ONLY, рекурсия не выполняется, и индекс помечается как недействительный. (ALTER INDEX ... ATTACH PARTITION помечает индекс как действительный, как только все секции получат соответствующие индексы). Однако следует отметить, что любой раздел, созданный в будущем с использованием CREATE TABLE ... PARTITION OF, автоматически будет иметь соответствующий индекс, независимо от того, указана ли опция ONLY.

Для методов индексирования, поддерживающих упорядоченные сканирования (в настоящее время только B-дерево), можно указать необязательные предложения ASC, DESC, NULLS FIRST и/или NULLS LAST, чтобы изменить порядок сортировки индекса. Поскольку упорядоченный индекс может быть просканирован как в прямом, так и в обратном направлении, обычно нет необходимости создавать одностолбцовый индекс с сортировкой DESC - такой порядок сортировки уже доступен с обычным индексом. Значение этих опций заключается в том, что можно создавать многоколоночные индексы, соответствующие порядку сортировки, запрошенному в запросе с смешанным порядком, например, SELECT ... ORDER BY x ASC, y DESC. Опции NULLS полезны, если вам нужно поддерживать поведение “nulls sort low”, а не используемое по умолчанию “nulls sort high” в запросах, которые зависят от индексов, чтобы избежать сортировки.

Система регулярно собирает статистику по всем столбцам таблицы. Недавно созданные не выражениями индексы могут немедленно использовать эту статистику для определения полезности индекса. Для новых индексов выражений необходимо запустить ANALYZE или дождаться, пока процесс автоочистки проанализирует таблицу и сгенерирует статистику для этих индексов.

Для большинства методов индексации скорость создания индекса зависит от значения параметра maintenance_work_mem. Большие значения уменьшают время, необходимое для создания индекса, при условии, что вы не устанавливаете его больше, чем фактически доступное количество памяти, что может привести к обмену данными на машине.

Tantor SE может создавать индексы, используя несколько ЦП, чтобы обрабатывать строки таблицы быстрее. Эта функция называется параллельная сборка индекса. Для методов индексации, поддерживающих параллельную сборку индексов (в настоящее время только B-дерево), maintenance_work_mem указывает максимальный объем памяти, который может использоваться каждой операцией сборки индекса в целом, независимо от количества запущенных рабочих процессов. Обычно, модель стоимости автоматически определяет, сколько рабочих процессов следует запросить, если это необходимо.

Параллельная сборка индексов может получить выгоду от увеличения параметра maintenance_work_mem, в то время как эквивалентная последовательная сборка индекса не увидит никакой или незначительной выгоды. Обратите внимание, что параметр maintenance_work_mem может влиять на количество запрашиваемых рабочих процессов, так как параллельные рабочие процессы должны иметь как минимум долю 32MB от общего бюджета maintenance_work_mem. Также должна быть оставшаяся доля 32MB для процесса-лидера. Увеличение параметра max_parallel_maintenance_workers может позволить использовать больше рабочих процессов, что уменьшит время, необходимое для создания индекса, при условии, что сборка индекса не ограничена вводом-выводом. Конечно, также должна быть достаточная производительность ЦП, которая в противном случае оставалась бы неиспользуемой.

Установка значения для parallel_workers через ALTER TABLE непосредственно управляет количеством параллельных рабочих процессов, которые будут запрошены при выполнении CREATE INDEX на таблице. Это обходит полностью модель стоимости и предотвращает влияние maintenance_work_mem на количество запрашиваемых параллельных рабочих процессов. Установка значения parallel_workers равным 0 через ALTER TABLE отключит построение параллельных индексов на таблице во всех случаях.

Подсказка

Вы можете захотеть сбросить параметр parallel_workers после его установки в процессе настройки построения индекса. Это позволяет избежать непреднамеренных изменений в планах запросов, поскольку параметр parallel_workers влияет на все параллельные сканирования таблиц.

В то время как команда CREATE INDEX с опцией CONCURRENTLY поддерживает параллельную сборку без особых ограничений, фактически выполняется только первое сканирование таблицы параллельно.

Используйте DROP INDEX, чтобы удалить индекс.

Как и любая долгосрочная транзакция, CREATE INDEX на таблице может повлиять на то, какие кортежи могут быть удалены параллельной командой VACUUM на любой другой таблице.

Предыдущие версии Tantor SE также имели метод индексации R-tree. Этот метод был удален, потому что он не имел значительных преимуществ по сравнению с методом GiST. Если указано USING rtree, CREATE INDEX будет интерпретировать его как USING gist, чтобы упростить преобразование старых баз данных в GiST.

Каждый запущенный бэкенд, выполняющий команду CREATE INDEX, будет отображать свой прогресс в представлении pg_stat_progress_create_index. Подробности см. в разделе Раздел 27.4.2.

Примеры

Для создания уникального индекса B-дерева на столбце title в таблице films: 

CREATE UNIQUE INDEX title_idx ON films (title);

Для создания уникального индекса B-дерева на столбце title с включенными столбцами director и rating в таблице films: 

CREATE UNIQUE INDEX title_idx ON films (title) INCLUDE (director, rating);

Для создания индекса B-Tree с отключенной дедупликацией: 

CREATE INDEX title_idx ON films (title) WITH (deduplicate_items = off);

Для создания индекса на выражении lower(title), позволяющего эффективно выполнять регистронезависимые поиски: 

CREATE INDEX ON films ((lower(title)));

(В этом примере мы решили опустить имя индекса, поэтому система выберет имя, обычно films_lower_idx).

Для создания индекса с кастомным правилом сортировки: 

CREATE INDEX title_idx_german ON films (title COLLATE "de_DE");

Для создания индекса с нестандартной сортировкой значений NULL: 

CREATE INDEX title_idx_nulls_low ON films (title NULLS FIRST);

Для создания индекса с нестандартным коэффициентом заполнения: 

CREATE UNIQUE INDEX title_idx ON films (title) WITH (fillfactor = 70);

Для создания индекса GIN с отключенной быстрой обновлением: 

CREATE INDEX gin_idx ON documents_table USING GIN (locations) WITH (fastupdate = off);

Для создания индекса на столбце code в таблице films и размещения индекса в табличном пространстве indexspace: 

CREATE INDEX code_idx ON films (code) TABLESPACE indexspace;

Для создания индекса GiST на атрибуте точки, чтобы мы могли эффективно использовать операторы box на результате функции преобразования: 

CREATE INDEX pointloc
    ON points USING gist (box(location,location));
SELECT * FROM points
    WHERE box(location,location) && '(0,0),(1,1)'::box;

Для создания индекса без блокировки записей в таблице: 

CREATE INDEX CONCURRENTLY sales_quantity_index ON sales_table (quantity);

Совместимость

CREATE INDEX - это расширение языка Tantor SE. В стандарте SQL нет положений о индексах.

Назад Наверх Далее
CREATE GROUP Начало CREATE LANGUAGE