Если реализовать подобный движок (memtx с "расширенным" журналом), то из железа, кажется, можно будет выжать по-максимуму: журнал и снепшоты пишутся на шпиндельные диски с кэшем записи в контроллерах (с батарейкой или ssd-кэшем), memtx не отвлекается на выгрузку данных и обрабатывает миллион транзакций в секунду, журналы подъедаются сторонними обработчиками и, по мере подъедания, забываются по внешней команде.
Мне вот стало любопытно: а что мешает добавить в спейсы по полю reason, в которых собственно и записывается вся информация по транзакции и почему именно эта запись и всё такое?
Можно добавить reason-ы, просто это лишнее место в RAM/CPU cache, которое движок будет обрабатывать. Разница копеечная, но если ставить целью выжать всё, что можно...
Когда мы говорим о памяти, нужно иметь в виду, что есть ограниченный ресурс - кэш на процессорном чипе, время ожидания (latency) запроса из основной RAM. Копейки, предлагаю сейчас не обсуждать.
В принципе идея ограничения функционала , если уж приходится ей пользоваться не должна приводить к отключению фичи целиком. Достаточно отключить те вещи которые не работают иди работают непредсказуемо, например забанить неявные касты
Если мы забаним неявные касты, то все равно поведение будет немного странным - с индексом сравнение работает, без индекса - нет.
Насчет имплисит кастов вообще разговор сложный, никак не можем окончательно решить, удалять или нет. В тот момент когда в очередной раз решаем удалить имплисит касты, повяляется человек, который с утверждением "А у постгри они есть!" умудряется забанить уже принятое решение и все начинается сначала
Смотрите, тип данных это множество значений и набор операций . Скалар - супертип, он объединяет множество значений всех скалярных типов. Но операции типа сравнения определены только в пределах конкретного подмножества, например int, и нельзя расширить семантику операции подмножества на весь тип скалар. Поэтому для скалар определена своя семантика операции сравнения. Рабочий вариант - сделать так чтобы эта операция работала только для проиндексированных значений. Ещё один рабочий вариант - чтобы она работала и не для проиндексированных значений, но требовать в этом случае явный каст к скалару чтобы не было многозначности.
Я стараюсь придерживаться мнения, что не существует значений типа скаляр, но есть такое поле. Т.е. каст к скаляру не будет давать ничего (кроме каста из map/array - там будет ошибка). Исходя из этого, мне кажется логичней запретить сравнение, где это возможно, т.е. хотя бы в сравнении без индекса
В любом случае, я надеюсь что мы сможем отказаться от имплисит кастов и проблема со скалярами больше не будет такой острой, как сейчас
Отказаться совсем? У постгреса нет типа скаляр. Что мешает оставить имплицит касты лишь там где они есть в анси, это строки, даты и числа в некоторых контекстах, и убрать для всего остального?
тут мне кажется надо ориентироваться не на постгрю, а на ответ на вопрос: даст ли бан кастов профит по перфу и где. Если бан кастов даёт перф - банить. Если нет - не банить.
Если на этапе разбора SQL заполнять значения в скалярах, то кажется что перф будет одинаковый и с кастами и без. но это не точно