Comments 7
А не было мысли сравнить реализации еще и по производительности, измерив время выборки значений КВС, например, для миллиона сгенерированных случайных данных?
Для КВС практического смысла нет. Я не зря нашел ограничение сверху и ввел его в ТЗ. Количество данных получилось ограниченное и небольшой, поэтому даже без индексов это работало бы быстро.
Но при желании можно наполнить базу и милионами записей. Для этого я и завел эти схемы в docker. Любой читатель может себе склонировать, запустить и поиграться с идексами и количеством данных. Все sql для этого есть в репозитории.
Может я не точно выразился, но я имел ввиду миллион записей водителей со случайным возрастом и стажем, что вполне нормально для страховой компании, а не миллион записей КВС.
А как это влияет на способ хранения КВС? Джоиним по FK, расставляем ключи. Профит. Не тестил, но не вижу ни каких специфичных проблем которые появятся именно из-за range. Все укладывается в обычные истории с большими таблицами и их связями с другими таблицами. Опять же, тестовый стенд с данными есть в docker. При желании можно нагенерить туда случайных юзеров и проверить что в итоге будет.
B-tree и GIST все же очень разные индексы. А GIST вообще группа индексов, реализуемых методами соответствующего класса для разных типов индексируемых данных. То есть GIST для intrange и для box - вообще то разные реализации R-tree. Поэтому время выборки по индексу при JOIN должно различаться. Насколько это будет заметно?
Сохраняем диапазон в виде box типа