Melkijdbms_developerНу а B+-Tree там есть, надо признать.
Неа.
Деревья (разные!) могут быть в содержимом страниц конкретных access method (AM)
Может быть потом когда-нибудь допилят pluggable storage и опять же на уровне чуть выше страницы данных можно будет найти дерево.
А heap - банальная вульгарная куча
Это уже не важно. Чаще всего там какое-то B+-Tree.

Hawkmoondbms_developerС точки зрения системы хранения страничек Б-Дерева, нет ничего кроме страничек, набитых Key=Val, где в Val эта ваша вся доменно-столбцовая хрень и нам на уровне системы хранения страничек Б-Дерева совершенно пофиг на это.

Нет, студент, ты так слона не продашь диплом/диссер не защитишь.
потому что в СУБД под значением подразумевается допустимое значение домена. И если ты будешь замечательно рассказывать о ключе-значении чуваку, знающему реляционную АЛГЕБРУ, то ты порвешь мозг ему, также как порвал мозг всем тут.



Только проблема будет в том, что обладатель ученой степени - он, а защищаешься ты.
И со своим "ну плутон это земля, что тут непонятного. И марс земля, и луна земля." и агрессивным навязыванием своего языка, вместо использования сложившегося термина "планета/планетоид" пойдешь дорабатывать свою работу ты.

Я бы как рецензент отправил бы человека, приславшего такую статью, далеко.
Э-э-э, мы не говорим про СУБД и про реляционную алгебру.

Melkijdbms_developerЭто уже не важно.
Так если не важно - то при чём тут postgresql?
Берёте Transactional Information Systems Theory, Algorithms, and the Practice of Concurrency Control and Recovery авторства Gerhard Weikum и Gottfried Vossen и читаете. Про чекпойнты там тоже написано.
Мы обсуждаем систему checkpoint в постгресе. А реляционная алгебра и что точно хранится в страничках при этом - не очень важно.
Ваш кэпушка.

Alex URSvyegorovAlex URS,

pg_prewarm и цитата Тома — они несколько о другом.
Мы тут обсуждаем Нам рассказывают про механизмы попадающие под ‘D’ (Durability), и там важна другого рода производительность.

если брать в целом - согласен
статью читал, но не понимаю одно:
если нам впаривают, что Key = Value, то это не так. Реляция это связь, но не Key - Value.

Нет, этого вам не впаривают.
Игнорируйте впустую возбудившихся.

Scott Tigerdbms_developer, главная ошибка автора текста по ссылке состоит в том, что он пытается натянуть видимо хорошо ему знакомую терминологию из условного Redis на совершенно по-другому устроенный PostgreSQL. Как результат, понять логику рассуждений сложно, ибо она построена на совершенно абсурдных предположениях. Для начала надо понять, что для постгреса неприменима логика восстановления в памяти состояния из дисковой копии ("снапшота"), ибо первичным является собственно состояние на диске, а память используется как буфер, временно хранящий обрабатываемые данные, причём размер этого буфера обычно несопоставимо меньше объёма данных, хранящихся на диске (в файлах).
Это понятно, но это не принципиально для темы обсужления.

Ясно, что для СУБД типично то, что дисковое/ленточное/бумажное хранилище первично по отношению к памяти. В этом смысле СУБД не пытается накатить состояние памяти из "снепшота", чтобы работать, и ОЗУ рассматривается чисто как кеш. Но это совершенно не отличается от того, как если бы у нас существовала некая Key=Value, которая умеет вытеснять из памяти часть данных и по необходимости ходить за ними на диск. Я считаю, что в современном мире систем хранения эта граница давно уже размыта. Что считать
"in-memory" хранилкой, что "дисковой" - уже строго деления давно нет. Все они держат что-то в памяти, что-то имеют право держать на диске. Если система держит на диске 95% своих данных, то "in-memory" или нет? А если через 1 минуту подгрузила всё в память и больше не выгружала - она стала "in memory" от этого? В общем это всё софистика с точки зрения темы топика. Мы можем реализовать тот же Redis на базе B+-Tree, а не на базе хеш-таблички и научить Redis при старте не зачитывать в память всё, а подгружать блоки B+-Tree при необходимости, а при желании скинуть что-то на диск, помимо записи журнала, иногда делать тот же самый checkpoint процесс со скидыванием грязных страничек.

Так что тема разговора просто про способ синхронизировать с диском набор грязных блоков, реализованный в Постгресе в виде постгресного checkpoint процесса. Что там в этих блоках лежало - многоверсионные кортежи, реляционно связанные с чем-то там ещё или просто россыпь Key=Value - имеет нулевую важность.

Alex URSdbms_developerЯсно, что для СУБД типично то, что дисковое/ленточное/бумажное хранилище первично по отношению к памяти. В этом смысле СУБД не пытается накатить состояние памяти из "снепшота", чтобы работать, и ОЗУ рассматривается чисто как кеш. Но это совершенно не отличается от того, как если бы у нас существовала некая Key=Value, которая умеет вытеснять из памяти часть данных и по необходимости ходить за ними на диск. Я считаю, что в современном мире систем хранения эта граница давно уже размыта. Что считать
"in-memory" хранилкой, что "дисковой" - уже строго деления давно нет. Все они держат что-то в памяти, что-то имеют право держать на диске. Если система держит на диске 95% своих данных, то "in-memory" или нет? А если через 1 минуту подгрузила всё в память и больше не выгружала - она стала "in memory" от этого? В общем это всё софистика с точки зрения темы топика. Мы можем реализовать тот же Redis на базе B+-Tree, а не на базе хеш-таблички и научить Redis при старте не зачитывать в память всё, а подгружать блоки B+-Tree при необходимости, а при желании скинуть что-то на диск, помимо записи журнала, иногда делать тот же самый checkpoint процесс со скидыванием грязных страничек.

Так что тема разговора просто про способ синхронизировать с диском набор грязных блоков, реализованный в Постгресе в виде постгресного checkpoint процесса. Что там в этих блоках лежало - многоверсионные кортежи, реляционно связанные с чем-то там ещё или просто россыпь Key=Value - имеет нулевую важность.

смешались в кучу кони, люди (с)
1. по поводу нулевой важности - прочитайте про архитектуру Berkeley DB
2. система in-memory - это не совсем то, что вы пишите - это не место - это механизм, который подразумевает хранение в in-memory как минимум индексов к объекту

вообще я не понимаю такую вещь - SQL на порядок надёжнее, чем NOSQL из за математического способа структуризации, которого в NOSQL нет - как можно от NOSQL "тянуть" checkpoint в SQL(RDBMS) - это не логично
Не очень понял в чём вопрос.
У вас есть B+-Tree в большом файлике.
Вы нагрузили в память каких-то блоков этого B+-Tree, какими-то элементарными операциями меняете содержимое этих блоков, возможно порождаете новые.
Задача: хотелось бы скинуть на диск изменённые блоки. Как-нибудь.

Checkout process в Постгресе решает эту задачу своим способом.
Этот способ и обсуждается.
Чё там в этих блоках валяется - строки таблиц, Key=Value или ещё какая хрень - вообще пофигу. SQL тоже.