там был ответ от Питера Гейгена в ветке, который очень хорошо охарактеризовал тест, как оторванный от реальных практических метрик (синтетический).
и привёл ссылки, в том числе на тесты Facebook-а, в которых общего выигрыша от LSM практически и нет (хотя он явно наблюдается, если рассматривать определённые параметры).
вот и Ярослав об этом же пишет.

Если я хочу хранить в базе содержимое email-писем (портянка HTML), и мне по нему не нужно искать, я выгадаю что-нибудь, если буду использовать сжатие перед помещением в базу? Или оно и без того попадет в TOAST и сожмется?

TOAST, грубо говоря, сжимает слабо, но быстро (относительно современных методов сжатия).
А уж выгадаете или нет — решайте на основании этого (по-моему, степень сжатия проще просто протестировать на существенном количестве e-mails).

Спасибо

Postgres может сам закешировать данные ?

Да

shared_buffers

«Но оно может, и через это «может» совершается диалектический скачок. Во, во!.. Смотрите! Видали, как оно может?»

А если не сам, это как?

Есть одна маленькая проблемка. Индексы не хранят информации о видимости строк, а значит с offset эти счетчики числа дочерних нод никак не помогут, если только мы не говорим о редком случае таблицы, в которую почти никто не пишет.
Вкупе с проблемами, которые выше описали (блокировки при апдейтах вышестоящих нод), овчинка выделки не стоит.

В этом случае мог бы помочь кластеризованный индекс (если я правильно это назвал), но в pg нет такого почему-то, только heap.

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

Кластеризация не поможет идентифицировать неактуальные записи, а лишь даст упорядоченность  индекса в соответствии с данными на диске

Видимо поможет что-то типа index organized table в oracle.

Не, вы похоже про команду cluster говорите, а я про то, чего нету в pg

Да, выглядит тем самым.

Ну, опять же, для вычисления правильного offset, вам придётся индекс просматривать. Простые счетчики на вышестоящих узлах дерева не помогут, вы ведь не будете значения счетчика для каждой транзакции дублировать.

Опять-таки, теоретически всё это решаемо, вопрос именно в том, что это очень много работы, скорее всего существенная потеря производительности и concurrency (и, на практике, надёжности), а на выходе — пшик (выгода для 0.0001% запросов, например).

Я не подтосовывал колоду. Я сравнивал Постгрес с RocksDB где LSM вполне себе ACID-ая. И с своим собственным расширением lsm3, которое на самом деле не фига не LSM, а "вариация на тему", сделанная на базе 3ёх обчных постгресовый btree, со всеми сопутствующими ACIDными гарантиями.

Вот приведённая ссылка на in-memory  беннчмарк, как раз на мой взгляд совершенно не уместна, потому как преимущество LSM как раз обеспечивается в том случае, когда индекс не влезает в память.

Я не утверждал, что LSM всегда и на любой нагрузке  лучше,чем B-Tree. Как раз наоборот. Но есть use case, на котором оно однозначно и убедительно выигрывает: вставки случайных ключей в большую тблицу с запасом не влезающую в память. Насколько это "синтетический"use case? Я не знаю. Но у нас в ПгПро было множество заказчиков, у которых профиль нагрузки был именно такой.

Почему в данном случае классическое Б-Дерево тормозит?Потому чтобы сделать поиск или вставку случайного ключа нужно прочитать несколько (зависит от глубины дерева) страниц с диска. Обычно это 1-2 страницы, верхушка дерева всё таки влезает в кэш. Среднее время чтения с жёсткого диска 10msec. Т.е. 100 таких операций в секунду. Соотвественно даже если нам надо читать всего одну листьевую страничку у нас TPS-ы получаются ограниченными этой 100-ей. В NVM скорость случайных чтений на порядок быстрее. Но всё ещё на порядки уступает скорости доступа к памяти.

LSM-у же не надо ничего читать с диска, чтобы сделать вставку. Он просто вставляет в ключ в верхушку пирамиды, которая расположена в памяти, а потом в бэкграунде оно сливается с нижними уровнями. Сливание - это последовательное чтение и запись, что диски умеют делать достаточно хорошо. Отсюда и получается разница в скорости в разы. Начиная с какого-то момента скорость  вставки в B-Tree начинает резко падать пока не упирается в скорость случайного чтения. А скорость LSM-а остаётся более менее постоянной.

Кто не верит - может сам взять тест и проверить. Или написать свой. Требуется только соблюдение трёх условий:
- преобладание вставок, причём без проверок уникальности
- случайное распределение ключей
- индекс не влезает в память
Как видно - это достаточно ограниченный сценарий. Поэтому речь не коим образом не идёт о замене  B-Treа  на LSM.
Но понимать когда LSM может обеспечит существенный выигрыш в скорости - весьма ИМХО полезно

Да, про mvcc не подумал.
Но это решаемо, работы много будет, да. Т.е. можно хранить в узлах хранить версионную штуку для изменённой транзакции. Очевидно, что она одна, и для каждой транзакции её хранить не надо.
Не нужно думать, что mvcc позволяет вам прямо 3-10 изменений одной строки делать в один момент времени. Изменений всегда не больше 1. Так mvcc работает и мне не известно, где это работает по-другому.

Хорошо, я посмотрю статью, которую вы мне скинули выше про lmdb, посмотрю, что там Костя сделал, посмотрю про postgresql-ый btree, про который писал Виктор выше и потом ближе к концу недели подумаю, есть ли мне что ответить.