Глава 58. Определение интерфейса для индексных методов доступа
Содержание
В этой главе описывается интерфейс между ядром системы PostgreSQL и индексными методами доступа, которые управляют отдельными типами индексов. Ядро системы не знает об индексах ничего, кроме того, что описано здесь; благодаря этому можно реализовывать абсолютно новые типы индексов в рамках расширений.
Все индексы PostgreSQL являются, говоря на техническом уровне, вторичными индексами; то есть, они физически отделены от файла таблицы, к которой относятся. Каждый индекс хранится в собственном отдельном физическом отношении и описывается в отдельной записи в каталоге pg_class
. Содержимое индекса находится полностью под контролем соответствующего метода доступа. На практике все индексные методы доступа делят индексы на страницы стандартного размера, чтобы для обращения к содержимому индекса можно было задействовать обычный менеджер хранилища и менеджер буферов. (Более того, все существующие методы доступа используют одну структуру страницы, описанную в Разделе 63.6, и одинаковый формат заголовков кортежей индекса; но эти решения методам доступа не навязываются.)
Индекс по сути представляет собой сопоставление некоторых значений ключей данных с идентификаторами кортежей, TID (Tuple Identifier), или версиями строк в основной таблице индекса. TID состоит из номера блока и номера записи в этом блоке (см. Раздел 63.6). Этой информации достаточно, чтобы выбрать определённую версию строки из таблицы. Индексы сами по себе не знают, что в модели MVCC у одной логической строки может быть несколько существующих версий; для индекса каждый кортеж — независимый объект, которому нужна своя запись в индексе. Таким образом, при изменении строки для неё всегда заново создаются новые записи индекса, даже если значения ключа не изменились. (Кортежи HOT представляют собой исключение из этого утверждения; но индексы всё равно не имеют с этим дела.) Записи индексов для мёртвых кортежей высвобождаются (при очистке), когда высвобождаются сами мёртвые кортежи.
F.28. mchar
The mchar
module provides additional data types for compatibility with Microsoft SQL Server (MS SQL).
F.28.1. Overview
This module has been designed to improve 1C Enterprise support, most popular Russian CRM and ERP system.
It implements types MCHAR and MVARCHAR, which are bug-to-bug compatible with MS SQL CHAR and VARCHAR respectively. Additionally, these types use the ICU library for comparison and case conversion, so their behavior is identical across different operating systems.
Postgres Pro also includes citext extension which provides types similar to MCHAR. But this extension doesn't emulate MS-SQL behavior concerning end-of-value whitespace.
Differences from Postgres Pro standard CHAR and VARCHAR are:
Case insensitive comparison
Handling of the whitespace at the end of string
These types are always stored as two-byte unicode value regardless of database encoding.
F.28.2. Additional types
mchar
— analog of the MS SQL char typemvarchar
— analog of the MS SQL varchar type
F.28.3. MCHAR and MVARCHAR features
Defines
length(str)
functionDefines
substr(str, pos[, length])
functionDefines
||
operator, which would be applied to concatenate any (mchar and mvarchar) argumentsDefines set of operators:
<
,<=
,=
,>=
,>
for case-insensitive comparison (ICU)Defines set of operators:
&<
,&<=
,&=
,&>=
,&>
to case-sensitive comparison (ICU)Implicit cast between
mchar
andmvarchar
typesB-tree and Hash-index support
The
LIKE [ESCAPE]
operator supportThe
SIMILAR TO [ESCAPE]
operator supportThe ~ operator (POSIX regexp) support
Index support for the LIKE operator
F.28.4. Authors
Oleg Bartunov <oleg@sai.msu.ru>
Teodor Sigaev <teodor@sigaev.ru>