Size: a a a

2021 June 25

VV

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

VV

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

BG

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

BG

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

VV

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

BG

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

VV

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

KO

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

KO

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

MI

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

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

VS

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

VG

Vladislav Grubov in Tarantool
не, < можно использовать и с числами и со строками, поэтому аргументы не кастятся, и луа по честному кидает ошибку:
tarantool> "50" < 100
---
- error: '[string "return "50" < 100"]:1: attempt to compare string with number'
источник

KO

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

MI

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

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

KO

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

MI

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

DO

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

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

DO

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

DO

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

WHERE
  my_scalar_field > $1
ORDER
BY
  my_scalar_field
источник

MI

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