65.2. Функции для индексных методов доступа #
Индексный метод доступа должен определить в IndexAmRoutine
следующие функции построения и обслуживания индексов:
IndexBuildResult * ambuild (Relation heapRelation, Relation indexRelation, IndexInfo *indexInfo);
Строит новый индекс. Отношение индекса уже физически создано, но пока пусто. Оно должно быть наполнено фиксированными данными, которые требуются методу доступа, и записями для всех кортежей, уже существующих в таблице. Обычно функция ambuild
вызывает table_index_build_scan()
для поиска в таблице существующих кортежей и для вычисления ключей, которые должны вставляться в этот индекс. Эта функция должна возвращать структуру, выделенную вызовом palloc и содержащую статистику нового индекса.
void ambuildempty (Relation indexRelation);
Создаёт пустой индекс и записывает его в слой инициализации (INIT_FORKNUM
) данного отношения. Этот метод вызывается только для нежурналируемых индексов; пустой индекс, записанный в слой инициализации, будет копироваться в основной слой отношения при каждом перезапуске сервера.
bool aminsert (Relation indexRelation, Datum *values, bool *isnull, ItemPointer heap_tid, Relation heapRelation, IndexUniqueCheck checkUnique, bool indexUnchanged, IndexInfo *indexInfo);
Вставляет новый кортеж в существующий индекс. В массивах values
и isnull
передаются значения ключа, которые должны быть проиндексированы, а в heap_tid
— идентификатор индексируемого кортежа (TID). Если метод доступа поддерживает уникальные индексы (флаг amcanunique
установлен), параметр checkUnique
указывает, какая проверка уникальности должна выполняться. Это зависит от того, является ли ограничение уникальности откладываемым; за подробностями обратитесь к Разделу 65.5. Обычно параметр heapRelation
нужен методу доступа только для проверки уникальности (так как он должен обратиться к основным данным, чтобы убедиться в актуальности кортежа).
Булево значение indexUnchanged
даёт «подсказку» о природе индексируемого кортежа. Когда это значение — true, кортеж является дубликатом некоторого существующего кортежа в индексе. Новый кортеж является логически неизменённым, созданным для новой версии MVCC. Такие кортежи появляются, когда выполняется операция UPDATE
, которая не меняет никакие столбцы, охватываемые индексом, но тем не менее требует добавления новой версии кортежа в индекс. Опираясь на эту «подсказку», индексный метод может принять решение о выполнении восходящего удаления индексных кортежей в частях индекса, где скапливается много версий одной и той же логической строки. Заметьте, что изменение неключевого столбца не влияет на значение indexUnchanged
. В коде ядра определяется значение indexUnchanged
каждого кортежа при использовании подхода с низкими издержками, который допускает как ложные положительные, так и ложные отрицательные результаты. Индексные МД не должны рассматривать indexUnchanged
как авторитетный источник информации о видимости кортежа или версионировании.
Возвращаемый функцией булев результат имеет значение, только когда параметр checkUnique
равен UNIQUE_CHECK_PARTIAL
. В этом случае результат true означает, что новая запись признана уникальной, тогда как false означает, что она может быть неуникальной (и требуется назначить отложенную проверку уникальности). В других случаях рекомендуется возвращать постоянный результат false.
Некоторые индексы могут индексировать не все кортежи. Если кортеж не будет индексирован, aminsert
должна просто завершиться, не делая ничего.
Если индексный МД хочет кешировать данные между операциями добавления в индекс в одном операторе SQL, он может выделить память в indexInfo->ii_Context
и сохранить указатель на эти данные в поле indexInfo->ii_AmCache
(которое изначально равно NULL).
IndexBulkDeleteResult * ambulkdelete (IndexVacuumInfo *info, IndexBulkDeleteResult *stats, IndexBulkDeleteCallback callback, void *callback_state);
Удаляет кортеж(и) из индекса. Это операция «массового удаления», которая предположительно будет реализована путём сканирования всего индекса и проверки для каждой записи, должна ли она удаляться. Переданная функция callback
должна вызываться в стиле callback(
с результатом bool, который говорит, должна ли удаляться запись индекса, на которую указывает передаваемый TID. Возвращать эта функция должна NULL или структуру, выделенную вызовом palloc и содержащую статистику результата удаления. NULL можно вернуть, если никакая информация не должна передаваться в TID
, callback_state)amvacuumcleanup
.
Из-за ограничения maintenance_work_mem
процедура ambulkdelete
может вызываться несколько раз, когда удалению подлежит большое количество кортежей. В аргументе stats
передаётся результат предыдущего вызова для данного индекса (при первом вызове в ходе операции VACUUM
он содержит NULL). Это позволяет методу доступа накапливать статистику в процессе всей операции. Обычно ambulkdelete
модифицирует и возвращает одну и ту же структуру, если в stats
передаётся не NULL.
IndexBulkDeleteResult * amvacuumcleanup (IndexVacuumInfo *info, IndexBulkDeleteResult *stats);
Провести уборку после операции VACUUM
(до этого ambulkdelete
могла вызываться несколько или ноль раз). От этой функции не требуется ничего, кроме как выдать статистику по индексу, но она может произвести массовую уборку, например, высвободить пустые страницы индекса. В stats
ей передаётся структура, возвращённая при последнем вызове ambulkdelete
, либо NULL, если ambulkdelete
не вызывалась, так как никакие кортежи удалять не требовалось. Эта функция должна возвращать NULL или структуру, выделенную вызовом palloc. Содержащаяся в этой структуре статистика будет отражена в записи в pg_class
и попадёт в вывод команды VACUUM
, если она выполнялась с указанием VERBOSE
. NULL может возвращаться, если индекс вовсе не изменился в процессе операции VACUUM
, но в противном случае должна возвращаться корректная статистика.
amvacuumcleanup
также вызывается в конце операции ANALYZE
. В этом случае stats
всегда NULL и любое возвращаемое значение игнорируется. Этот вариант вызова можно распознать, проверив поле info->analyze_only
. При таком вызове методу доступа рекомендуется ничего не делать, кроме как провести уборку после добавления данных, и только в рабочем процессе автоочистки.
bool amcanreturn (Relation indexRelation, int attno);
Проверяет, поддерживается ли сканирование только индекса для заданного столбца, когда из индекса можно получить исходное значение столбца. Атрибуты нумеруются с 1, то есть для первого столбца attno равен 1. Возвращает true, если такое сканирование поддерживается, а иначе — false. Эта функция должна всегда возвращать true для неключевых столбцов (если таковые поддерживаются), так как неключевые столбцы, значения которые нельзя извлечь, не имеют смысла. Если индексный метод доступа в принципе не поддерживает сканирование только индекса, в поле amcanreturn
его структуры IndexAmRoutine
можно записать NULL.
void amcostestimate (PlannerInfo *root, IndexPath *path, double loop_count, Cost *indexStartupCost, Cost *indexTotalCost, Selectivity *indexSelectivity, double *indexCorrelation, double *indexPages);
Рассчитывает примерную стоимость сканирования индекса. Эта функция полностью описывается ниже в Разделе 65.6.
bytea * amoptions (ArrayType *reloptions, bool validate);
Разбирает и проверяет массив параметров для индекса. Эта функция вызывается, только когда для индекса задан отличный от NULL массив reloptions. Массив reloptions
состоит из элементов типа text
, содержащих записи вида имя
=
значение
. Данная функция должна получить значение типа bytea
, которое будет скопировано в поле rd_options
записи индекса в relcache. Содержимое этого значения bytea
определяется самим методом доступа; большинство стандартных методов доступа помещают в него структуру StdRdOptions
. Когда параметр validate
равен true, эта функция должна выдать подходящее сообщение об ошибке, если какие-либо параметры нераспознаны или имеют недопустимые значения; если же validate
равен false, некорректные записи должны просто игнорироваться. (В validate
передаётся false, когда параметры уже загружены в pg_catalog
; при этом неверная запись может быть обнаружена, только если в методе доступа поменялись правила обработки параметров, и в этом случае стоит просто игнорировать такие записи.) NULL можно вернуть, когда нужно получить поведение по умолчанию.
bool amproperty (Oid index_oid, int attno, IndexAMProperty prop, const char *propname, bool *res, bool *isnull);
Процедура amproperty
позволяет индексным методам доступа переопределять стандартное поведение функции pg_index_column_has_property
и связанных с ней. Если метод доступа не проявляет никаких особенностей при запросе свойств индексов, поле amproperty
в структуре IndexAmRoutine
может содержать NULL. В противном случае процедура amproperty
будет вызываться с нулевыми параметрами index_oid
и attno
при вызове pg_indexam_has_property
, либо с корректным index_oid
и нулевым attno
при вызове pg_index_has_property
, либо с корректным index_oid
и положительным attno
при вызове pg_index_column_has_property
. В prop
передаётся значение перечисления, указывающее на проверяемое значение, а в propname
— строка с именем свойства. Если код ядра не распознаёт имя свойства, в prop
передаётся AMPROP_UNKNOWN
. Методы доступа могут воспринимать нестандартные имена свойств, проверяя propname
на совпадение (для согласованности с кодом ядра используйте для проверки pg_strcasecmp
); для имён, известных коду ядра, лучше проверять prop
. Если процедура amproperty
возвращает true
, это значит, что она установила результат проверки свойства: она должна задать в *res
возвращаемое логическое значение или установить в *isnull
значение true
, чтобы возвратить NULL. (Перед вызовом обе упомянутые переменные инициализируются значением false
.) Если amproperty
возвращает false
, код ядра переключается на обычную логику определения результата проверки свойства.
Методы доступа, поддерживающие операторы упорядочивания, должны реализовывать проверку свойства AMPROP_DISTANCE_ORDERABLE
, так как код ядра не знает, как это сделать и возвращает NULL. Также может быть полезно реализовать проверку AMPROP_RETURNABLE
, если это можно сделать проще, чем обращаясь к индексу и вызывая amcanreturn
(что делает код ядра по умолчанию). Для всех остальных стандартных свойств поведение ядра по умолчанию можно считать удовлетворительным.
char * ambuildphasename (int64 phasenum);
Возвращает текстовое название переданной фазы построения индекса. Номера фаз передаются в процессе построения индекса функции pgstat_progress_update_param
. Названия фаз показываются в представлении pg_stat_progress_create_index
.
bool amvalidate (Oid opclassoid);
Проверяет записи в каталоге для заданного класса операторов, насколько это может сделать метод доступа. Например, это может включать проверку, все ли необходимые опорные функции реализованы. Функция amvalidate
должна вернуть false, если класс операторов непригоден к использованию. Сообщения о проблеме следует выдать через ereport
, как правило, на уровне INFO
.
void amadjustmembers (Oid opfamilyoid, Oid opclassoid, List *operators, List *functions);
Проверяет предложенные новые операторы и функции-члены семейства операторов, насколько метод доступа позволяет это сделать, и задаёт виды их зависимостей, если подразумеваемые по умолчанию неудовлетворительны Эта функция вызывается во время выполнения команд CREATE OPERATOR CLASS
и ALTER OPERATOR FAMILY ADD
; в последнем случае значение opclassoid
равно InvalidOid
. В аргументах типа List
передаются списки элементов структуры OpFamilyMember
. Проверки, выполняемые данной функцией, обычно являются подмножеством проверок, выполняемых amvalidate
, поскольку предполагается, что amadjustmembers
не видит полный набор членов. Например, в этой функции будет разумным проверить сигнатуры опорной функции, но не проверять, предоставляются ли все необходимые опорные функции. О любых проблемах можно сообщить, выдав ошибку. Связанные с зависимостями поля структуры OpFamilyMember
инициализируются кодом ядра — если выполняется CREATE OPERATOR CLASS
, создаются жёсткие зависимости от класса операторов, а если выполняется ALTER OPERATOR FAMILY ADD
— мягкие зависимости от семейства операторов. Функция amadjustmembers
может скорректировать эти поля, если более уместно другое поведение. Например, GIN, GiST и SP-GiST всегда устанавливают для операторов-членов мягкую зависимость от семейства операторов, поскольку в этих типах индексов связь между оператором и классом оператора относительно слаба; поэтому есть смысл разрешить свободное добавление и удаление членов операторов. Для необязательных опорных функций обычно также устанавливаются мягкие зависимости, чтобы при необходимости их можно было удалить.
Цель индекса, конечно, в том, чтобы поддерживать поиск кортежей, соответствующих индексируемому условию WHERE
, по ограничению или ключу поиска. Сканирование индекса описывается более полно ниже, в Разделе 65.3. Индексный метод доступа может поддерживать «простое» сканирование, сканирование по «битовой карте» или и то, и другое. Метод доступа должен или может реализовывать следующие функции, связанные со сканированием:
IndexScanDesc ambeginscan (Relation indexRelation, int nkeys, int norderbys);
Подготавливает метод к сканированию индекса. В параметрах nkeys
и norderbys
задаётся количество операторов условия и сортировки, которые будут задействованы при сканировании; это может быть полезно для выделения памяти. Заметьте, что фактические значения ключей сканирования в этот момент ещё не предоставляются. В результате функция должна выдать структуру, выделенную средствами palloc. В связи с особенностями реализации, метод доступа должен создать эту структуру, вызвав RelationGetIndexScan()
. В большинстве случаев все действия ambeginscan
сводятся только к выполнению этого вызова и, возможно, получению блокировок; всё самое интересное при запуске сканирования индекса происходит в amrescan
.
void amrescan (IndexScanDesc scan, ScanKey keys, int nkeys, ScanKey orderbys, int norderbys);
Запускает или перезапускает сканирование индекса, возможно, с новыми ключами сканирования. (Для перезапуска сканирования с ранее переданными ключами в keys
и/или orderbys
передаётся NULL.) Заметьте, что количество ключей или операторов сортировки не может превышать значения, поступившие в ambeginscan
. На практике возможность перезапуска используется, когда в соединении со вложенным циклом выбирается новый внешний кортеж, так что требуется сравнение с новым ключом, но структура ключей сканирования не меняется.
bool amgettuple (IndexScanDesc scan, ScanDirection direction);
Выбирает следующий кортеж в ходе данного сканирования, с передвижением по индексу в заданном направлении (вперёд или назад). Возвращает true, если кортеж был получен, или false, если подходящих кортежей не осталось. В случае успеха в структуре scan
сохраняется TID кортежа. Заметьте, что под «успехом» здесь подразумевается только, что индекс содержит запись, соответствующую ключам сканирования, а не то, что данный кортеж обязательно существует в данных или оказывается видимым в снимке вызывающего субъекта. При положительном результате amgettuple
должна также установить для свойства scan->xs_recheck
значение true или false. Значение false будет означать, что запись индекса точно соответствует ключам сканирования, а true — что есть сомнение в этом, так что условия, представленные ключами сканирования, необходимо ещё раз перепроверить для фактического кортежа, когда он будет получен. Это свойство введено для поддержки «неточных» операторов индексов. Заметьте, что такая перепроверка касается только условий сканирования; предикат частичного индекса (если он имеется) никогда не перепроверяется кодом, вызывающим amgettuple
.
Если индекс поддерживает сканирование только индекса (то есть amcanreturn
выдаёт true для каких-либо его столбцов), то в случае успеха метод доступа должен также проверить флаг scan->xs_want_itup
и, если он установлен, должен вернуть исходные индексированные данные для этой записи индекса. В столбцах, для которых amcanreturn
выдаёт false, можно вернуть null. Данные могут возвращаться посредством указателя на IndexTuple
, сохранённого в scan->xs_itup
, с дескриптором scan->xs_itupdesc
; либо посредством указателя на HeapTuple
, сохранённого в scan->xs_hitup
, с дескриптором кортежа scan->xs_hitupdesc
. (Второй вариант должен использоваться при восстановлении данных, которые могут не уместиться в IndexTuple
.) В любом случае за управление целевой областью данных, определяемой этим указателем, отвечает метод доступа. Данные должны оставаться актуальными как минимум до следующего вызова amgettuple
, amrescan
или amendscan
в процессе сканирования.
Функция amgettuple
должна быть реализована, только если метод доступа поддерживает «простое» сканирование индекса. В противном случае поле amgettuple
в структуре IndexAmRoutine
должно содержать NULL.
int64 amgetbitmap (IndexScanDesc scan, TIDBitmap *tbm);
Выбирает все кортежи для данного сканирования и добавляет их в передаваемую вызывающим кодом структуру TIDBitmap
(то есть, получает логическое объединение множества TID выбранных кортежей с множеством, уже записанным в битовой карте). Возвращает эта функция число полученных кортежей (это может быть только приблизительная оценка; например, некоторые методы доступа не учитывают повторяющиеся значения). Добавляя идентификаторы кортежей в битовую карту, amgetbitmap
может обозначить, что для этих кортежей нужно перепроверить условия сканирования. Для этого так же, как и в amgettuple
, устанавливается выходной параметр xs_recheck
. Замечание: в текущей реализации эта возможность увязывается с возможностью неточного хранения самих битовых карт, таким образом вызывающий код перепроверяет для отмеченных кортежей и условия сканирования, и предикат частичного индекса (если он имеется). Однако так может быть не всегда. Функции amgetbitmap
и amgettuple
не могут использоваться в одном сканировании индекса; есть и другие ограничения в применении amgetbitmap
, описанные в Разделе 65.3.
Функция amgetbitmap
должна быть реализована, только если метод доступа поддерживает сканирование индекса «по битовой карте». В противном случае поле amgetbitmap
в структуре IndexAmRoutine
должно содержать NULL.
void amendscan (IndexScanDesc scan);
Завершает сканирование и освобождает ресурсы. Саму структуру scan
освобождать не следует, но любые блокировки или закрепления объектов, установленные внутри метода доступа, должны быть сняты.
void ammarkpos (IndexScanDesc scan);
Помечает текущую позицию сканирования. Метод доступа должен поддерживать сохранение только одной позиции в процессе сканирования.
Функция ammarkpos
должна быть реализована, только если метод доступа поддерживает сканирование по порядку. Если это не так, в поле ammarkpos
в структуре IndexAmRoutine
можно записать NULL.
void amrestrpos (IndexScanDesc scan);
Восстанавливает позицию сканирования, отмеченную последней.
Функция amrestrpos
должна быть реализована, только если метод доступа поддерживает сканирование по порядку. Если это не так, в поле amrestrpos
в структуре IndexAmRoutine
можно записать NULL.
Помимо обычного сканирования некоторые типы индексов могут поддерживать параллельное сканирование индекса, что позволяет осуществлять совместное сканирование индекса нескольким обслуживающим процессам. Для этого метод доступа должен организовать работу так, чтобы каждый из взаимодействующих процессов возвращал подмножество кортежей, которое бы возвращалось при обычном, не параллельном сканировании, и таким образом, чтобы объединение этих подмножеств совпадало с множеством кортежей, возвращаемых при обычном сканировании. Более того, чтобы не требовалась глобальная сортировка кортежей, возвращаемых при параллельном сканировании, порядок кортежей в подмножествах, выдаваемых всеми взаимодействующими процессами, должен соответствовать запрошенному. Для поддержки параллельного сканирования по индексу должны быть реализованы следующие функции:
Size amestimateparallelscan (void);
Рассчитывает и возвращает объём (в байтах) в динамической разделяемой памяти, который может потребоваться для осуществления параллельного сканирования. (Этот объём дополняет, а не заменяет объём памяти, затребованный для данных, независимо от МД, в ParallelIndexScanDescData
.)
Эту функцию можно не реализовывать для методов доступа, которые не поддерживают параллельное сканирование, или для которых объём дополнительно требующейся памяти равен нулю.
void aminitparallelscan (void *target);
Эта функция будет вызываться для инициализации области динамической разделяемой памяти в начале параллельного сканирования. Параметр target
будет указывать на область объёма, не меньшего, чем возвратила функция amestimateparallelscan
, и данная функция может хранить в этой области любые нужные ей данные.
Эту функцию можно не реализовывать для методов доступа, которые не поддерживают параллельное сканирование, или когда выделенная область в разделяемой памяти не требует инициализации.
void amparallelrescan (IndexScanDesc scan);
Эта функция, если её реализовать, будет вызываться перед перезапуском параллельного сканирования индекса. Она должна сбросить всё разделяемое состояние, установленное функцией aminitparallelscan
, с тем, чтобы такое сканирование перезапустилось с начала.
F.30. ltree — hierarchical tree-like data type #
This module implements a data type ltree
for representing labels of data stored in a hierarchical tree-like structure. Extensive facilities for searching through label trees are provided.
This module is considered “trusted”, that is, it can be installed by non-superusers who have CREATE
privilege on the current database.
F.30.1. Definitions #
A label is a sequence of alphanumeric characters, underscores, and hyphens. Valid alphanumeric character ranges are dependent on the database locale. For example, in C locale, the characters A-Za-z0-9_-
are allowed. Labels must be no more than 1000 characters long.
Examples: 42
, Personal_Services
A label path is a sequence of zero or more labels separated by dots, for example L1.L2.L3
, representing a path from the root of a hierarchical tree to a particular node. The length of a label path cannot exceed 65535 labels.
Example: Top.Countries.Europe.Russia
The ltree
module provides several data types:
ltree
stores a label path.lquery
represents a regular-expression-like pattern for matchingltree
values. A simple word matches that label within a path. A star symbol (*
) matches zero or more labels. These can be joined with dots to form a pattern that must match the whole label path. For example:foo Match the exact label path
foo
*.foo.* Match any label path containing the labelfoo
*.foo Match any label path whose last label isfoo
Both star symbols and simple words can be quantified to restrict how many labels they can match:
*{
n
} Match exactlyn
labels *{n
,} Match at leastn
labels *{n
,m
} Match at leastn
but not more thanm
labels *{,m
} Match at mostm
labels — same as *{0,m
} foo{n
,m
} Match at leastn
but not more thanm
occurrences offoo
foo{,} Match any number of occurrences offoo
, including zeroIn the absence of any explicit quantifier, the default for a star symbol is to match any number of labels (that is,
{,}
) while the default for a non-star item is to match exactly once (that is,{1}
).There are several modifiers that can be put at the end of a non-star
lquery
item to make it match more than just the exact match:@ Match case-insensitively, for example
a@
matchesA
* Match any label with this prefix, for examplefoo*
matchesfoobar
% Match initial underscore-separated wordsThe behavior of
%
is a bit complicated. It tries to match words rather than the entire label. For examplefoo_bar%
matchesfoo_bar_baz
but notfoo_barbaz
. If combined with*
, prefix matching applies to each word separately, for examplefoo_bar%*
matchesfoo1_bar2_baz
but notfoo1_br2_baz
.Also, you can write several possibly-modified non-star items separated with
|
(OR) to match any of those items, and you can put!
(NOT) at the start of a non-star group to match any label that doesn't match any of the alternatives. A quantifier, if any, goes at the end of the group; it means some number of matches for the group as a whole (that is, some number of labels matching or not matching any of the alternatives).Here's an annotated example of
lquery
:Top.*{0,2}.sport*@.!football|tennis{1,}.Russ*|Spain a. b. c. d. e.
This query will match any label path that:
begins with the label
Top
and next has zero to two labels before
a label beginning with the case-insensitive prefix
sport
then has one or more labels, none of which match
football
nortennis
and then ends with a label beginning with
Russ
or exactly matchingSpain
.
ltxtquery
represents a full-text-search-like pattern for matchingltree
values. Anltxtquery
value contains words, possibly with the modifiers@
,*
,%
at the end; the modifiers have the same meanings as inlquery
. Words can be combined with&
(AND),|
(OR),!
(NOT), and parentheses. The key difference fromlquery
is thatltxtquery
matches words without regard to their position in the label path.Here's an example
ltxtquery
:Europe & Russia*@ & !Transportation
This will match paths that contain the label
Europe
and any label beginning withRussia
(case-insensitive), but not paths containing the labelTransportation
. The location of these words within the path is not important. Also, when%
is used, the word can be matched to any underscore-separated word within a label, regardless of position.
Note: ltxtquery
allows whitespace between symbols, but ltree
and lquery
do not.
F.30.2. Operators and Functions #
Type ltree
has the usual comparison operators =
, <>
, <
, >
, <=
, >=
. Comparison sorts in the order of a tree traversal, with the children of a node sorted by label text. In addition, the specialized operators shown in Table F.17 are available.
Table F.17. ltree
Operators
Operator Description |
---|
Is left argument an ancestor of right (or equal)? |
Is left argument a descendant of right (or equal)? |
Does |
Does |
Does |
Concatenates |
Converts text to |
Does array contain an ancestor of |
Does array contain a descendant of |
Does array contain any path matching |
Does |
Does array contain any path matching |
Returns first array entry that is an ancestor of |
Returns first array entry that is a descendant of |
Returns first array entry that matches |
Returns first array entry that matches |
The operators <@
, @>
, @
and ~
have analogues ^<@
, ^@>
, ^@
, ^~
, which are the same except they do not use indexes. These are useful only for testing purposes.
The available functions are shown in Table F.18.
Table F.18. ltree
Functions
F.30.3. Indexes #
ltree
supports several types of indexes that can speed up the indicated operators:
B-tree index over
ltree
:<
,<=
,=
,>=
,>
Hash index over
ltree
:=
GiST index over
ltree
(gist_ltree_ops
opclass):<
,<=
,=
,>=
,>
,@>
,<@
,@
,~
,?
gist_ltree_ops
GiST opclass approximates a set of path labels as a bitmap signature. Its optional integer parametersiglen
determines the signature length in bytes. The default signature length is 8 bytes. The length must be a positive multiple ofint
alignment (4 bytes on most machines)) up to 2024. Longer signatures lead to a more precise search (scanning a smaller fraction of the index and fewer heap pages), at the cost of a larger index.Example of creating such an index with the default signature length of 8 bytes:
CREATE INDEX path_gist_idx ON test USING GIST (path);
Example of creating such an index with a signature length of 100 bytes:
CREATE INDEX path_gist_idx ON test USING GIST (path gist_ltree_ops(siglen=100));
GiST index over
ltree[]
(gist__ltree_ops
opclass):ltree[] <@ ltree
,ltree @> ltree[]
,@
,~
,?
gist__ltree_ops
GiST opclass works similarly togist_ltree_ops
and also takes signature length as a parameter. The default value ofsiglen
ingist__ltree_ops
is 28 bytes.Example of creating such an index with the default signature length of 28 bytes:
CREATE INDEX path_gist_idx ON test USING GIST (array_path);
Example of creating such an index with a signature length of 100 bytes:
CREATE INDEX path_gist_idx ON test USING GIST (array_path gist__ltree_ops(siglen=100));
Note: This index type is lossy.
F.30.4. Example #
This example uses the following data (also available in file contrib/ltree/ltreetest.sql
in the source distribution):
CREATE TABLE test (path ltree); INSERT INTO test VALUES ('Top'); INSERT INTO test VALUES ('Top.Science'); INSERT INTO test VALUES ('Top.Science.Astronomy'); INSERT INTO test VALUES ('Top.Science.Astronomy.Astrophysics'); INSERT INTO test VALUES ('Top.Science.Astronomy.Cosmology'); INSERT INTO test VALUES ('Top.Hobbies'); INSERT INTO test VALUES ('Top.Hobbies.Amateurs_Astronomy'); INSERT INTO test VALUES ('Top.Collections'); INSERT INTO test VALUES ('Top.Collections.Pictures'); INSERT INTO test VALUES ('Top.Collections.Pictures.Astronomy'); INSERT INTO test VALUES ('Top.Collections.Pictures.Astronomy.Stars'); INSERT INTO test VALUES ('Top.Collections.Pictures.Astronomy.Galaxies'); INSERT INTO test VALUES ('Top.Collections.Pictures.Astronomy.Astronauts'); CREATE INDEX path_gist_idx ON test USING GIST (path); CREATE INDEX path_idx ON test USING BTREE (path); CREATE INDEX path_hash_idx ON test USING HASH (path);
Now, we have a table test
populated with data describing the hierarchy shown below:
Top / | \ Science Hobbies Collections / | \ Astronomy Amateurs_Astronomy Pictures / \ | Astrophysics Cosmology Astronomy / | \ Galaxies Stars Astronauts
We can do inheritance:
ltreetest=> SELECT path FROM test WHERE path <@ 'Top.Science'; path ------------------------------------ Top.Science Top.Science.Astronomy Top.Science.Astronomy.Astrophysics Top.Science.Astronomy.Cosmology (4 rows)
Here are some examples of path matching:
ltreetest=> SELECT path FROM test WHERE path ~ '*.Astronomy.*'; path ----------------------------------------------- Top.Science.Astronomy Top.Science.Astronomy.Astrophysics Top.Science.Astronomy.Cosmology Top.Collections.Pictures.Astronomy Top.Collections.Pictures.Astronomy.Stars Top.Collections.Pictures.Astronomy.Galaxies Top.Collections.Pictures.Astronomy.Astronauts (7 rows) ltreetest=> SELECT path FROM test WHERE path ~ '*.!pictures@.Astronomy.*'; path ------------------------------------ Top.Science.Astronomy Top.Science.Astronomy.Astrophysics Top.Science.Astronomy.Cosmology (3 rows)
Here are some examples of full text search:
ltreetest=> SELECT path FROM test WHERE path @ 'Astro*% & !pictures@'; path ------------------------------------ Top.Science.Astronomy Top.Science.Astronomy.Astrophysics Top.Science.Astronomy.Cosmology Top.Hobbies.Amateurs_Astronomy (4 rows) ltreetest=> SELECT path FROM test WHERE path @ 'Astro* & !pictures@'; path ------------------------------------ Top.Science.Astronomy Top.Science.Astronomy.Astrophysics Top.Science.Astronomy.Cosmology (3 rows)
Path construction using functions:
ltreetest=> SELECT subpath(path,0,2)||'Space'||subpath(path,2) FROM test WHERE path <@ 'Top.Science.Astronomy'; ?column? ------------------------------------------ Top.Science.Space.Astronomy Top.Science.Space.Astronomy.Astrophysics Top.Science.Space.Astronomy.Cosmology (3 rows)
We could simplify this by creating an SQL function that inserts a label at a specified position in a path:
CREATE FUNCTION ins_label(ltree, int, text) RETURNS ltree AS 'select subpath($1,0,$2) || $3 || subpath($1,$2);' LANGUAGE SQL IMMUTABLE; ltreetest=> SELECT ins_label(path,2,'Space') FROM test WHERE path <@ 'Top.Science.Astronomy'; ins_label ------------------------------------------ Top.Science.Space.Astronomy Top.Science.Space.Astronomy.Astrophysics Top.Science.Space.Astronomy.Cosmology (3 rows)
F.30.5. Transforms #
The ltree_plpython3u
extension implements transforms for the ltree
type for PL/Python. If installed and specified when creating a function, ltree
values are mapped to Python lists. (The reverse is currently not supported, however.)
Caution
It is strongly recommended that the transform extension be installed in the same schema as ltree
. Otherwise there are installation-time security hazards if a transform extension's schema contains objects defined by a hostile user.
F.30.6. Authors #
All work was done by Teodor Sigaev (<teodor@stack.net>
) and Oleg Bartunov (<oleg@sai.msu.su>
). See http://www.sai.msu.su/~megera/postgres/gist/ for additional information. Authors would like to thank Eugeny Rodichev for helpful discussions. Comments and bug reports are welcome.