А если в узлах хранить дельты на каждую транзакцию, то все узлы будут сильно распухать, зато конкурентоность увеличится....

Эх, тогда придется по старинке)

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

Индексы

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

Поробуйте в pg_stat_activity посмотреть, блокируются ли запросы кем-то

> Я не подтосовывал колоду.

Что касается этого benchmark, мне тоже кажется, что тест "оторванный от реальных практических метрик (синтетический)". Я не имел в виду того, что Вы так поступили преднамеренно.

> Я сравнивал Постгрес с RocksDB где LSM вполне себе ACID-ая.

Дьявол в деталях.

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

То есть против того, что в типичном случае (а это не когда индекс "влезает в память", а когда его "горячая" часть туда влезает, а она может быть в сотни раз меньше!) LSM проигрывает, у Вас возражений нет? ;)
Тогда пойдём дальше, вот ссылка на RocksDB vs LMDB уже в существенной степени не в RAM: https://www.mdeditor.tw/pl/2cBB

> Я не утверждал, что LSM всегда и на любой нагрузке лучше, чем B-Tree. Как раз наоборот.

Вот именно.

> Насколько это "синтетический" use case?

Может быть, разработчики других general-purpose RDBMS кардинально ошибаются, когда считают этот случай [очень] редким (и, соответственно, не используют LSM trees для on-disk indexes)?
Мне он тоже кажется очень редким, но уверенности у меня нет.

А давайте спросим присутствующих.

> Но есть use case, на котором оно однозначно и убедительно выигрывает вставки случайных ключей в большую таблицу, с запасом не влезающую в память.

Коллеги, это редкий случай, как вам кажется?

> Но у нас в ПгПро было множество заказчиков, у которых профиль нагрузки был именно такой.

Непустое множество, Вы имели в виду? (шутка) Т.е. статистика у Вас есть?

> СЛиваение - это последовательное чтение и запись, что диски умеют делать достаточно хорошо.

Примерно так же, как современные диски умеют делать и произвольную... но всё это в общем и целом "теоретически" верно.

> Кто не верит - может сам взять тест и проверить. Или написать свой.

А у кого нет времени заниматься этой ерундой этим — может помолчать? ;)
Нет, ну правда, хочется потратить время как то полезнее / приятнее, чем на то, чтобы убеждаться в очевидных, но не относящихся к делу (IMNSHO) вещах.

> Как видно - это достаточно ограниченный сценарий.

Вот именно. Поэтому (по "сопутствующим" причинам, точнее), по моему мнению, LSM в самом PostgreSQL не нужен.
Но если кто-то готов написать, выложить и поддерживать качественное расширение — им и карты в руки.

> Но понимать когда LSM может обеспечит существенный выигрыш в скорости - весьма ИМХО полезно.

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

Столкнулся с таким случаем, при вызове  
EXECUTE 'alter subscription sub_1 refresh publication' ;
из триггера, убивается postgres и уходит в постоянный ребут.

Раз "не возвращается", покажите просто EXPLAIN, без (ANALYZE, BUFFERS) (но и всё остальное, конечно!), что поделаешь.

Какие могут быть негативные последсвия при изменении параметра block_size для уже работающей базы? Причем интересует изменение как в большую, так и в меньшую сторону.

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

это шутка?

В смысле?

Нет, это то, что Вам нужно показать.
Если отказываетесь — лучше поищите помощь где-то в другом месте, честное слово.

А мне кажется, что ему нужно посмотреть в pg_stat_activity, потому что в его сообщении говорится, что ЛЮБОЙ запрос к этой таблице уходит в себя, а значит и запрос select * from table limit 1, после чего смысла смотреть в план я не вижу

ребзи, у меня к примеру 1,2,3,4....412, 414, 415 и т.д. Вот мне надо свободный индекс взять 413, чтобы присвоить его юзеру. Каким образом я могу до него достучаться с помощью запроса в субд? Или тут только взять массив этих элементов и уже самому построить логику внутри среды

Тоже возможно, да. Но он же нам это скажет (что и обычный EXPLAIN "завис"), я надеюсь. ;)

А какая версия PostgreSQL? Если последний minor любой версии — пишите bug report, что ж.

А в архиве точно бинарники есть или это всё же исходники которые скомпилировать нужно?