Под "расширенным журналом" я в данном случае понимаю журнал изменений состояния ОЗУ с указанием причин, почему изменения были произведены.

Если реализовать подобный движок (memtx с "расширенным" журналом), то из железа, кажется, можно будет выжать по-максимуму: журнал и снепшоты пишутся на шпиндельные диски с кэшем записи в контроллерах (с батарейкой или ssd-кэшем), memtx не отвлекается на выгрузку данных и обрабатывает миллион транзакций в секунду, журналы подъедаются сторонними обработчиками и, по мере подъедания, забываются по внешней команде.

Мне вот стало любопытно: а что мешает добавить в спейсы по полю reason, в которых собственно и записывается вся информация по транзакции и почему именно эта запись и всё такое?

Ну и заполнять это поле самому, в любом случае для разных задач разные метаданные требуются

Можно добавить reason-ы,  просто это лишнее место в RAM/CPU cache, которое движок будет обрабатывать. Разница копеечная, но если ставить целью выжать всё, что можно...

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

Когда мы говорим о памяти, нужно иметь в виду, что есть ограниченный ресурс - кэш на процессорном чипе, время ожидания (latency) запроса из основной RAM. Копейки, предлагаю сейчас не обсуждать.

Почему бы в случае сравнения со скаляром тупо не забанить implicit cast?

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

Если мы забаним неявные касты, то все равно поведение будет немного странным - с индексом сравнение работает, без индекса - нет.

Насчет имплисит кастов вообще разговор сложный, никак не можем окончательно решить, удалять или нет. В тот момент когда в очередной раз решаем удалить имплисит касты, повяляется человек, который с утверждением "А у постгри они есть!" умудряется забанить уже принятое решение и все начинается сначала

Поведение не будет страннее, чем в луа. Ты например не сможешь в луа написать uuid < 100 (хотя “50” < 100 наверное проканает, но это со строками так)

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

tarantool> "50" < 100
---
- error: '[string "return "50" < 100"]:1: attempt to compare string with number'

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

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

В любом случае, я надеюсь что мы сможем отказаться от имплисит кастов и проблема со скалярами больше не будет такой острой, как сейчас

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

Насколько я знаю, в анси нет имплисит кастов из строк в что-то еще

тут мне кажется надо ориентироваться не на постгрю, а на ответ на вопрос: даст ли бан кастов профит по перфу и где.
Если бан кастов даёт перф - банить. Если нет - не банить.

Если на этапе разбора SQL заполнять значения в скалярах, то кажется что перф будет одинаковый и с кастами и без.
но это не точно

+ Для скаляра, думаю, бан имплисит кастов не заметит никто

Хотя если есть индекс, то кто-то захочет написать:

WHERE
   my_scalar_field > $1
ORDER

BY
  my_scalar_field

Т.е. это нормально, что если я сравню '1' и 2, то вне скаляра я получу, что 2 больше, а в скаляре - что '1' больше?