Ответ
Когда говорят об автоматическом хранении больших объектов в PostgreSQL, имеют в виду механизм TOAST (The Oversized-Attribute Storage Technique).
Это основной способ, которым PostgreSQL прозрачно для пользователя управляет значениями в полях (TEXT, JSONB, BYTEA, VARCHAR и др.), размер которых превышает ~2 КБ.
Как работает TOAST:
-
Порог срабатывания: PostgreSQL хранит строки таблицы в "страницах" фиксированного размера (обычно 8 КБ). Если одна строка со всеми её полями не помещается на страницу, TOAST пытается решить эту проблему.
-
Сжатие: Первым делом TOAST пытается сжать данные в "проблемных" полях с помощью быстрого алгоритма
pglz. Если после сжатия строка помещается на страницу, данные так и хранятся в сжатом виде. -
Вынос "Out-of-line": Если сжатие не помогло, PostgreSQL выносит большие данные из основной таблицы в специальную служебную TOAST-таблицу. В основной таблице остается только небольшой "указатель" (pointer) на эти данные.
-
Чанки: В TOAST-таблице данные нарезаются на фрагменты (чанки) размером до 2 КБ, что позволяет эффективно считывать только необходимые части больших объектов.
Этот механизм полностью прозрачен для приложения. Когда вы делаете SELECT, PostgreSQL автоматически "собирает" данные обратно: распаковывает или подтягивает из TOAST-таблицы.
Отличие от Large Objects (pg_largeobject):
Не стоит путать TOAST с API для Large Objects. Large Objects — это более старый, непрозрачный механизм. Он требует от разработчика явных действий:
- Создать объект и получить его ID (
lo_create). - Работать с ним как с файлом (открывать, читать, писать по частям, закрывать).
- Хранить в таблице только ID этого объекта.
Large Objects полезны для хранения очень больших данных (сотни мегабайт или гигабайты), с которыми нужно работать потоково, не загружая их целиком в память.
Ответ 18+ 🔞
А, слушай, про эту вашу TOAST-технологию в PostgreSQL! Ну, это же просто пиздец какой-то гениальный костыль, ей-богу.
Вот представь: у тебя в таблице поле TEXT, и ты туда впихнул целую «Войну и мир», блядь. А база данных устроена так, что строки живут в страницах по 8 КБ. И как, сука, туда этот роман влезет? Никак! Вот тут-то и включается TOAST, этот скромный герой, который всех спасает.
Сначала он пытается быть вежливым: «Давай, дружок, сожму тебя немножко, алгоритмом pglz». Если после сжатия всё влазит — красота, живём дальше. Но если нет — начинается магия, блядь.
Тогда TOAST берёт твои огромные данные, такие: «Ну ты, блядь, жирный кусок», — и выносит их нахуй из основной таблицы. В специальную, невидимую TOAST-таблицу. А в исходной строке оставляет только маленькую записочку, типа «ищи там, вон в том углу». В TOAST-таблице данные ещё и на кусочки режут, по 2 КБ, чтобы удобнее было.
И самое охуенное — тебе, как разработчику, вообще похуй! Ты просто пишешь SELECT * FROM books, а PostgreSQL сам всё незаметно собирает: достаёт из закромов, распаковывает и подаёт тебе на блюдечке. Полная прозрачность, блядь. Волшебство, да и только.
А теперь, смотри, не путай это с другим старым пердуном — Large Objects (pg_largeobject). Это совсем другая история, ёпта. Это как работать с файлами через базу. Там тебе надо самому, вручную:
- Создать объект, получить его ID (
lo_create). - Открыть его, как файл, читать/писать по частям.
- В своей таблице хранить только этот ID, как ссылку.
Этот механизм — для совсем уж конченых гигантов, на сотни мегабайт, когда нужно стримить данные, не загружая всё в память разом. Но он не прозрачный, с ним возни — овердохуища.
Так что запомни: TOAST — это твой невидимый друг, который прячет твои большие данные, чтобы не позориться. А Large Objects — это явный, старый интерфейс для работы с файлоподобными сущностями. Всё, вопрос закрыт, иди работай.