Digital Q.DataBase использует фиксированный размер страницы (обычно 8 КБ) и не позволяет кортежам пересекать границы страниц. По этой причине хранение очень больших значений полей напрямую невозможно. Для обхода данного ограничения большие значения полей сжимаются и/или разбиваются на несколько физических строк. Это происходит прозрачно для пользователя и лишь незначительно влияет на большую часть серверного кода. Эта методика получила шутливое название TOAST (или ««лучшее изобретение со времён нарезанного хлеба»»). The TOAST инфраструктура также используется для оптимизации обработки больших значений данных в оперативной памяти.

Только определенные типы данных поддерживают TOAST — нет необходимости накладывать дополнительные накладные расходы на типы данных, которые не могут содержать большие значения полей. Для поддержки TOAST, тип данных должен иметь представление переменной длины (структура varlena), в котором обычно первое четырехбайтовое слово любого хранимого значения содержит общую длину значения в байтах (включая само слово). TOAST не накладывает ограничений на остальную часть представления типа данных. Специальные представления, в совокупности называемые TOASTed-значениями , работают путем изменения или переинтерпретации этого начального слова длины. Поэтому функции уровня C, поддерживающие TOAST-ируемый тип данных, должны быть внимательны при обработке потенциально TOASTанных входных значений: входные данные могут не состоять из четырехбайтового слова длины и содержимого до тех пор, пока они не будут растостированы. (Обычно это выполняется путем вызова функции PG_DETOAST_DATUM перед выполнением любых операций с входным значением, но в некоторых случаях возможны более эффективные подходы. См. Раздел 5.1.13.1 для получения более подробных сведений.)

TOAST задействует два бита слова длины структуры varlena (старшие биты на машинах с порядком байтов big-endian, младшие биты на машинах с порядком байтов little-endian), ограничивая тем самым логический размер любого значения TOAST-ируемого типа данных до 1 ГБ (2³⁰ - 1 байт). Если оба бита равны нулю, значение является обычным не-TOASTрастостированным значением типа данных, а остальные биты слова длины определяют общий размер элемента данных (включая слово длины) в байтах. Если установлен самый старший или самый младший бит, значение имеет только однобайтовый заголовок вместо стандартного четырехбайтового заголовка, а остальные биты этого байта определяют общий размер данных (включая байт длины) в байтах. Данный альтернативный вариант поддерживает компактное хранение значений длиной менее 127 байт, позволяя при этом размеру данных увеличиваться до 1 ГБ при необходимости. Значения с однобайтовыми заголовками не выравниваются по каким-либо границам, в то время как значения с четырехбайтовыми заголовками выравниваются как минимум по четырехбайтовой границе; отсутствие выравнивающего заполнения обеспечивает дополнительную экономию пространства, весьма существенную для коротких значений. В качестве особого случая: если оставшиеся биты однобайтового заголовка равны нулю (что невозможно для длины, включающей заголовок), значение является указателем на внешние (out-of-line) данные с несколькими вариантами реализации, описанными ниже. Тип и размер такого TOAST pointer определяются кодом, хранящимся во втором байте элемента datum. Наконец, если старший или младший бит сброшен, а соседний бит установлен, содержимое данных является сжатым и должно быть распаковано перед использованием. В этом случае остальные биты четырехбайтового слова длины указывают общий размер сжатых данных, а не исходных. Обратите внимание, что сжатие также возможно для внестрочных данных, однако заголовок структуры varlena не указывает, было ли оно выполнено — содержимое TOAST на это указывает содержимое указателя.

Метод сжатия, используемый для данных, сжатых внутри или вне строки, можно выбрать для каждого столбца путем установки COMPRESSION параметра столбца в CREATE TABLE или ALTER TABLE. Для столбцов без явных настроек по умолчанию учитывается значение default_toast_compression параметра в момент вставки данных.

Как упоминалось ранее, существует несколько типов TOAST указателей datum. Старейшим и наиболее распространенным типом является указатель на внестрочные данные, хранящиеся в TOAST таблица таблице, которая отделена от таблицы, содержащей TOAST самом указателе datum. Эти расположенные на диске значения datum-указателей создаются TOAST кодом управления (в файле access/common/toast_internals.c) когда кортеж, предназначенный для записи на диск, слишком велик для хранения в исходном виде. Более подробная информация приведена в Раздел 7.15.2.1. В качестве альтернативы, TOAST указатель на данные может содержать ссылку на данные вне основного ряда (out-of-line), расположенные в другом месте в памяти. Такие данные являются кратковременными и никогда не записываются на диск, однако они полезны для исключения лишнего копирования и избыточной обработки больших значений. Подробности приведены в Раздел 7.15.2.2.

7.15.2.1. Внешнее хранилище TOAST на диске #

Если какие-либо столбцы таблицы поддерживают механизм TOAST-аемая, у таблицы будет связанная TOAST таблица, идентификатор OID которой хранится в соответствующей записи pg_class.reltoastrelid . Значения, сохраненные на диске с применением TOAST, содержатся в TOAST таблице, как более подробно описано ниже.

Значения вне основного ряда делятся (после сжатия, если оно применяется) на фрагменты размером не более TOAST_MAX_CHUNK_SIZE байт (по умолчанию это значение выбирается так, чтобы четыре строки фрагментов помещались на одной странице, что составляет около 2000 байт). Каждый фрагмент сохраняется как отдельная строка в TOAST таблица, относящаяся к основной таблице. Каждая TOAST таблица содержит столбцы chunk_id (идентификатор OID, идентифицирующий конкретное TOASTое значение), chunk_seq (порядковый номер фрагмента в значении), и chunk_data (фактические данные фрагмента). Уникальный индекс по chunk_id и chunk_seq обеспечивает быстрое извлечение значений. Указатель данных, представляющий вынесенное за пределы страницы значение на диске, TOASTое значение, таким образом, должен содержать идентификатор OID TOAST таблицы, в которой выполняется поиск, и идентификатор OID конкретного значения (его chunk_id). Для удобства в указателях данных также сохраняются логический размер данных (исходный размер несжатых данных), физический размер хранения (отличается при использовании сжатия) и метод сжатия, если он применялся. С учётом байтов заголовка структура varlena общий размер хранящегося на диске TOAST указателя данных составляет 18 байт независимо от фактического размера представляемого значения.

Данный каталог TOAST код управления срабатывает только в том случае, когда размер сохраняемой в таблице строки превышает TOAST_TUPLE_THRESHOLD байт (обычно 2 КБ). TOAST код будет сжимать и/или выносить значения полей во внешнее хранилище до тех пор, пока размер всей строки не станет меньше TOAST_TUPLE_TARGET байтов (также обычно 2 КБ, настраивается) или пока дальнейшее уменьшение размера станет невозможным. При выполнении операции UPDATE значения неизмененных полей обычно сохраняются в исходном виде; поэтому операция UPDATE для строки с вынесенными во внешнее хранилище значениями не влечет за собой TOAST дополнительных затрат, если ни одно из этих внешних значений не изменяется.

Данный каталог TOAST код управления TOAST предусматривает четыре различные стратегии хранения TOAST-able столбцов на диске:

PLAIN запрещает как сжатие, так и вынос данных во внешнее хранилище. Это единственно возможная стратегия для столбцов, не являющихсяTOAST-able типами данных.
EXTENDED допускает как сжатие, так и вынос данных во внешнее хранилище. Это стратегия по умолчанию для большинства TOAST-able типов данных. Сначала будет предпринята попытка сжатия, а затем — вынос во внешнее хранилище, если размер строки все еще слишком велик.
EXTERNAL допускает вынос данных во внешнее хранилище, но запрещает сжатие. Использование EXTERNAL позволит выполнять операции с подстроками в широких text и bytea столбцах более быстрыми (ценой увеличения занимаемого дискового пространства), так как эти операции оптимизированы для получения только необходимых фрагментов вынесенного значения, если оно не сжато.
MAIN разрешает сжатие, но запрещает вынос данных во внешнее хранилище (out-of-line storage). (На самом деле вынос данных во внешнее хранилище всё равно будет выполнен для таких столбцов, но только в качестве крайней меры, когда нет иного способа уменьшить размер строки до размера страницы.)

Для каждого TOAST-совместимого типа данных определена стратегия по умолчанию, однако стратегию для конкретного столбца таблицы можно переопределить через ALTER TABLE ... SET STORAGE.

TOAST_TUPLE_TARGET можно настроить для каждой таблицы с помощью команды ALTER TABLE ... SET (toast_tuple_target = N)

Данная схема имеет ряд преимуществ по сравнению с более прямолинейными подходами, такими как разрешение строкам данных занимать несколько страниц. При условии, что запросы обычно ограничиваются сравнениями с относительно небольшими значениями ключей, основная часть работы узла выполнения будет производиться с использованием основной записи строки. Большие значения TOASTатрибутов, вынесенных во внешнее хранилище, будут извлекаться (если они вообще запрашиваются) только в момент отправки результирующего набора данных клиенту. Таким образом, основная таблица занимает значительно меньше места, и в кеш разделяемых буферов помещается больше её строк, чем в случае отсутствия механизма внешнего хранения данных. Объемы наборов для сортировки также сокращаются, что позволяет чаще выполнять сортировку полностью в оперативной памяти. Проведенный тест показал, что таблица, содержащая типичные HTML-страницы и их URL-адреса, занимала примерно половину от исходного объема данных, включая TOAST TOAST-таблицу, при этом на основную таблицу приходилось лишь около 10 % всего объема данных (URL-адреса и некоторые небольшие HTML-страницы). Различий во времени выполнения по сравнению с не-TOASTсравнительная таблица, в которой все HTML-страницы были сокращены до 7 КБ, чтобы уместиться.

7.15.2.2. Внешнее хранилище TOAST в оперативной памяти #

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

Косвенные TOAST указатели просто ссылаются на некосвенное значение структуры varlena, хранящееся где-либо в памяти. Данный механизм изначально был создан для проверки концепции, но в настоящее время он используется при логическом декодировании во избежание возможного создания физических кортежей размером более 1 ГБ (что могло бы произойти при сборке всех внешних значений полей в один кортеж). Этот случай имеет ограниченное применение, так как создатель указателя несет полную ответственность за сохранность данных, на которые он ссылается, в течение всего времени существования указателя, а вспомогательная инфраструктура для этого отсутствует.

Расширенные TOAST указатели полезны для сложных типов данных, чье дисковое представление не вполне удобно для выполнения вычислений. Например, стандартное представление структуры varlena для Digital Q.DataBase массива включает сведения о размерности, битовую карту значений NULL (при их наличии), а также значения всех элементов по порядку. Если тип самих элементов имеет переменную длину, единственный способ найти N-й элемент заключается в последовательном просмотре всех предшествующих элементов. Такое представление оптимально для хранения на диске благодаря своей компактности, однако для выполнения вычислений с массивом удобнее использовать «расширенные» или «разобранное» представление, в котором определены начальные адреса всех элементов. TOAST Механизм указателей обеспечивает эту возможность, позволяя значению Datum, передаваемому по ссылке, указывать либо на стандартное значение структуры varlena (дисковое представление), либо на TOAST указатель, ссылающийся на расширенное представление в оперативной памяти. Особенности данного расширенного представления зависят от типа данных, однако оно должно иметь стандартный заголовок и соответствовать прочим требованиям API, изложенным в src/include/utils/expandeddatum.h. функции уровня C, работающие с данным типом данных, могут выбирать для обработки любое из представлений. Функции, которые не знают о расширенном представлении, а просто применяют PG_DETOAST_DATUM к своим входным аргументам, будут автоматически получать традиционную структуру varlena; таким образом, поддержку расширенного представления можно внедрять постепенно, по одной функции за раз.

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

Для всех типов находящихся в памяти TOAST указателей, TOAST код управления гарантирует, что такой указатель datum не будет случайно сохранен на диске. Находящиеся в памяти TOAST указатели автоматически расширяются до обычных встроенных структур varlena перед сохранением — и затем, возможно, преобразуются в дисковые TOAST указатели, если в противном случае содержащий их кортеж был бы слишком велик.

Наверх