История изменений

На всякий:

1. Никакие индексы тут не помогут, т.е. БД всегда должна будет прочитать все данные.

2. С ростом кол-ва данных сложность будет расти как O(N*N*L), т.е. довольно быстро узким местом станет вычисление, а не выборка или чтение с диска.

3. Если данных много и нужна скорость, то сами вычисления придется делать «на С» и задействовать AVX2/512 или GPU.

Соответственно, либо сделать хранимку на C (с правильной векторизацией) для postgresql, либо взять «тупой» локальный memory-mapped key-value storage.

Если нужна максимальная производительность при поиске, и нет возможности или смысла считать заранее, то придется брать libmdbx/LMDB и руками делить выборку на порции помещающиеся в L1/L2 (оптимальность зависит от CPU) и обрабатывать их параллельно (openmp), либо задействовать GPU.

На всякий:

1. Никакие индексы тут не помогут, т.е. БД всегда должна будет прочитать все данные.

2. С ростом кол-ва данных сложность будет расти как O(NNL), т.е. довольно быстро узким местом станет вычисление, а не выборка или чтение с диска.

3. Если данных много и нужна скорость, то сами вычисления придется делать «на С» и задействовать AVX2 или GPU.

Соответственно, либо сделать хранимку на C (с правильной векторизацией) для postgresql, либо взять «тупой» локальный memory-mapped key-value storage.

Если нужна максимальная производительность при поиске, и нет возможности или смысла считать заранее, то придется брать libmdbx/LMDB и руками делить выборку на порции помещающиеся в L1/L2 (оптимальность зависит от CPU) и обрабатывать их параллельно (openmp), либо задействовать GPU.