Глава 60. Определение интерфейса метода доступа к таблице#

Глава 60. Определение интерфейса метода доступа к таблице

Глава 60. Определение интерфейса метода доступа к таблице

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

Каждый метод доступа к таблице описывается строкой в системном каталоге pg_am. Запись pg_am указывает имя и функцию-обработчик для метода доступа к таблице. Эти записи могут быть созданы и удалены с помощью SQL-команд CREATE ACCESS METHOD и DROP ACCESS METHOD.

Функция обработчика метода доступа к таблице должна быть объявлена для принятия единственного аргумента типа internal и возвращать псевдотип table_am_handler. Аргумент является фиктивным значением, которое просто служит для предотвращения прямого вызова функций обработчика из SQL-команд. Результатом функции должен быть указатель на структуру типа TableAmRoutine, которая содержит все, что ядро кода должно знать, чтобы использовать метод доступа к таблице. Возвращаемое значение должно иметь время жизни сервера, что обычно достигается путем определения его как переменной static const в глобальной области видимости. Структура TableAmRoutine, также называемая API-структурой метода доступа, определяет поведение метода доступа с помощью обратных вызовов. Эти обратные вызовы являются указателями на обычные функции на языке C и не видимы или вызываемы на уровне SQL. Все обратные вызовы и их поведение определены в структуре TableAmRoutine (с комментариями внутри структуры, определяющими требования для обратных вызовов). Большинство обратных вызовов имеют оберточные функции, которые документируются с точки зрения пользователя (а не реализатора) метода доступа к таблице. Для получения подробной информации обратитесь к файлу src/include/access/tableam.h.

Для реализации метода доступа, разработчику обычно потребуется реализовать специфичный для данного метода доступа тип слота таблицы кортежей (см. src/include/executor/tuptable.h), который позволяет коду вне метода доступа сохранять ссылки на кортежи данного метода доступа и получать доступ к столбцам кортежа.

В настоящее время способ хранения данных в AM довольно свободен. Например, возможно, но не обязательно, использовать общий буферный кэш Postgres. В случае его использования, вероятно, имеет смысл использовать стандартную структуру страницы Tantor BE, описанную в Раздел 70.6.

Одним довольно большим ограничением API метода доступа к таблице является то, что в настоящее время, если AM хочет поддерживать модификации и/или индексы, необходимо, чтобы каждый кортеж имел идентификатор кортежа (TID), состоящий из номера блока и номера элемента (см. также Раздел 70.6). Строго говоря, не обязательно, чтобы подчасти TID имели тот же смысл, который они, например, имеют для heap, но если требуется поддержка сканирования битовой карты (это необязательно), номер блока должен обеспечивать локальность.

Для обеспечения безопасности от сбоев AM может использовать WAL PostgreSQL или собственную реализацию. Если выбран WAL, можно использовать либо Общие записи WAL, либо Собственный менеджер ресурсов WAL может быть реализован.

Для реализации транзакционной поддержки таким образом, чтобы различные методы доступа к таблицам могли быть использованы в рамках одной транзакции, вероятно, необходимо тесно интегрироваться с механизмом в файле src/backend/access/transam/xlog.c.

Любой разработчик нового table access method может обратиться к существующей реализации heap, находящейся в src/backend/access/heap/heapam_handler.c, чтобы узнать подробности ее реализации.