Насколько я понял, оно просто по всей таблице идет и гвардами фильтрует записи.

я на синтетическом примере не очень понимаю, что там вообще происходит.

У нас в флюссонике есть подобное место, где надо складировать в памяти данные про сегменты видео.

Каждый сегмент принадлежит стриму и у него есть utc.

Вот эти utc div 3600 = hour

Составной ключ получается:

`{"ort", 450955, 1623438607}`

Второе число — это номер часа. У тебя получаются таким образом бакеты, которые вполне неплохо режут пространство и их сильно меньше.

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

Да, а через next просто по очереди читает и это быстрее, т.к. Записи подряд идут

Нет, там фишка в том, что так как таблица ordered set, то можно сразу прыгнуть к нужному диапазону, а не всю таблицу шерстить.

На это сообщение ответил

Можно, но select_count этого не понимает, это не query planner от Oracle

делаем :ets.next с ключом {500. 0} и оно выдаст первый ключ. С обычными сетами такое не прокатывает.

Кое-что он таки понимает, если матчить {500, _}, то select таки оптимизирует, если верить докам.

В общем не актуально больше. Я на SQLite сделал, через Ecto. Работает - огонь. И в будущем смогу прикрутить запросы посложнее.

А если записать как {I, j, "I-j"} в ets?

тогда ключ получится не уникальный

там же ключ, это первый элемент кортежа

Точно (

Короче, составные ключи и прочие сложные запросы - никаких ЕТС и Мнезий.

значит у тебя что-то очень странное всё равно.

Ни в какой вселенной sqlite не работает быстро =)

Фишка в том что я использую SQLIte в памяти.

И оно обходит ETS на описанном сценарии с составным ключом. Я бенчил.

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

Видимо тормозит из-за того, что select_count всю таблицу до конца смотрит, а ручной матч обрывается сразу при первом несовпадении