CREATE INDEX

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

Синтаксис

CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] [ [ IF NOT EXISTS ] имя ] ON [ ONLY ] имя_таблицы [ USING метод ]
    ( { имя_столбца | ( выражение ) } [ COLLATE правило_сортировки ] [ класс_операторов  [ ( параметр_класса_операторов = значение [, ... ] ) ] ] [ ASC | DESC ] [ NULLS { FIRST | LAST } ] [, ...] )
    [ INCLUDE ( имя_столбца [, ...] ) ]
    [ NULLS [ NOT ] DISTINCT ]
    [ WITH ( параметр_хранения [= значение] [, ... ] ) ]
    [ TABLESPACE имя_табличного_пространства ]
    [ WHERE предикат ]

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

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

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

QHB предоставляет следующие индексные методы: B-дерево, хеш, GiST, SP-GiST, GIN и BRIN. Кроме того, пользователи могут определять свои собственные индексные методы, но это довольно сложно.

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

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

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

Параметры

UNIQUE

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

CONCURRENTLY

Если используется этот параметр, QHB будет строить индекс без установления каких-либо блокировок, предотвращающих параллельные добавления, изменения или удаление записей в таблице, тогда как стандартная операция построения индекса блокирует запись (но не чтение) в таблице до своего завершения. Существует несколько особенностей, которые следует учитывать при использовании этого параметра — см. параграф Неблокирующее построение индексов ниже.
Для временных таблиц команда CREATE INDEX всегда выполняется в неблокирующем режиме, поскольку к ним не может обратиться никакой другой сеанс, а кроме того, неблокирующее создание индекса менее затратно.

IF NOT EXISTS

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

INCLUDE

Необязательное предложение INCLUDE задает список столбцов, которые будут включены в индекс в качестве неключевых столбцов. Неключевой столбец не может использоваться в условии поиска для сканирования по индексу и игнорируется при анализе ограничения уникальности или исключения, применяемого индексом. Однако при сканировании только индекса содержимое неключевых столбцов может быть возвращено без необходимости обращения к таблице индекса, поскольку они доступны непосредственно из записи индекса. Таким образом, добавление неключевых столбцов позволяет использовать сканирование только индекса в тех запросах, где иначе оно было бы неприменимо.
В отношении добавления неключевых столбцов в индекс разумно проявлять консерватизм, особенно для широких столбцов. Если кортеж индекса превысит максимальный размер, допустимый для типа индекса, добавление данных завершится ошибкой. В любом случае неключевые столбцы дублируют данные из таблицы и раздувают размер индекса, что потенциально замедляет поиск. Более того, в индексе B-дереве, содержащем неключевой столбец, не будет работать дедупликация.
Столбцы, перечисленные в предложении INCLUDE, не нуждаются в соответствующих классах операторов; предложение может включать столбцы, типы данных которых не имеют классов операторов, определенных для данного метода доступа.
Выражения во включаемых столбцах не поддерживаются, так как они не могут использоваться при сканировании только индекса.
В настоящее время эту возможность поддерживают только методы доступа по индексам B-деревьям, GiST и SP-GiST. В таких индексах значения столбцов, перечисленных в предложении INCLUDE, включаются в кортежи на уровне листьев, которые соответствуют кортежам кучи, но не включаются в записи индекса верхнего уровня, используемые для навигации по деревьям.

имя

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

ONLY

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

имя_таблицы

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

метод

Имя используемого индексного метода. Возможные варианты: btree, hash, gist, spgist, gin, brin или методы доступа, установленные пользователем, например, bloom. По умолчанию используется метод btree.

имя_столбца

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

выражение

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

правило_сортировки

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

класс_операторов

Имя класса операторов. Подробную информацию см. ниже.

параметр_класса_операторов

Имя параметра класса операторов. Подробную информацию см. ниже.

ASC

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

DESC

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

NULLS FIRST

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

NULLS LAST

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

NULLS DISTINCT
NULLS NOT DISTINCT

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

параметр_хранения

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

имя_табличного_пространства

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

предикат

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

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

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

fillfactor (integer)

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

Индексы B-деревья по таблицам, где ожидается много добавлений и/или изменений, могут извлечь пользу из меньших значений коэффициента заполнения, установленных во время выполнения CREATE INDEX (до массовой загрузки данных в таблицу). Значения в диапазоне 50 — 90 могут эффективно «сгладить» интенсивность разделений страниц на начальной стадии существования индекса B-дерева (такое снижение коэффициента заполнения может даже уменьшить абсолютное количество разделений страниц, хотя этот эффект сильно зависит от рабочей нагрузки). Методика восходящего удаления индексов B-деревьев, описанная в подразделе Восходящее удаление индексных кортежей, зависит от наличия некоего «лишнего» места на страницах для сохранения «лишних» версий кортежей, и поэтому на нее может повлиять коэффициент заполнения (хотя обычно его эффект незначителен).

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

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

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

deduplicate_items (boolean)

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

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

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

buffering (enum)

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

Индексы GIN принимают другие параметры:

fastupdate (boolean)

Этот параметр управляет использованием методики быстрого обновления, описанной в разделе Методика быстрого обновления GIN. Это логический параметр: 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 (более подробную информацию см. в разделе Введение). Значение по умолчанию — 128.

autosummarize (boolean)

Определяет, будет ли поставлено в очередь выполнение обобщения для диапазона предыдущей страницы, когда выявляется добавление на следующей странице. Более подробную информацию см. в подразделе Обслуживание индекса. Значение по умолчанию — off (выключен).

Неблокирующее построение индексов

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

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

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

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

qhb=# \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 — нет.

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

Примечания

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

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

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

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

Для индексных методов, поддерживающих сканирование по порядку (в настоящее время это только В-дерево), можно изменить порядок сортировки индекса, указав необязательные предложения AS, DESC, NULLS FIRST и/или NULLS LAST. Поскольку упорядоченный индекс можно сканировать как вперед, так и назад, обычно нет смысла создавать индекс по убыванию (DESC) для одного столбца — этот порядок сортировки уже доступен с обычным индексом. Ценность этих параметров состоит в возможности создавать многостолбцовые индексы, которые будут соответствовать порядку сортировки, указанному в запросе со смешанным порядком сортировки, например SELECT ... ORDER BY x ASC, y DESC. Параметры NULLS полезны, когда в запросах, зависящих от индексов, требуется вместо стандартного «NULL вверху» реализовать поведение «NULL внизу», чтобы избежать этапов сортировки.

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

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

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

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

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

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

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

Для удаления индекса воспользуйтесь командой DROP INDEX.

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

Предыдущие выпуски QHB также поддерживали индексный метод R-дерево. Этот метод был удален, поскольку не имел существенных преимуществ по сравнению с методом GiST. Указание USING rtree в CREATE INDEX будет интерпретироваться как USING GiST, чтобы упростить перевод старых баз данных на GiST.

Каждый обслуживающий процесс, запускающий CREATE INDEX, будет записывать ход ее выполнения в представлении pg_stat_progress_create_index. Подробную информацию см. в подразделе Отчет о ходе выполнения CREATE INDEX.

Примеры

Создание уникального индекса 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-дерева с выключенным механизмом дедупликации:

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 по координатам точек, позволяющего эффективно использовать операторы для прямоугольников с результатом функции преобразования:

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 является языковым расширением QHB. В стандарте SQL нет положений для индексов.

См. также

ALTER INDEX, DROP INDEX, REINDEX, подраздел Отчет о ходе выполнения CREATE INDEX