Вроде как ещё было что-то кроме цитуса, тоже плагином

Там суть плагина в автоматизации управления партами (ну и шардирование, если надо)

Ну в общем суть ты понял - надо обмазываться патрицированием. У этих решений в блогах было более менее подробное описание что они делают, что бы добиться скорости. Можешь поискать, почитать и попробовать ручками и процедурами запилить простенькую версию их решения

да про партиционирования я знаю.. только многие задачирешаются и без этого. Давно все придумано и написано. Мне даже когда то попадался подобный сборник, но найти сейчас не могу

Без патрицирования - это наверное только через "функциональный" индекс от даты. Например по году + номер месяца, что бы хотя бы это быстро найти. Но большая таблица - это уже медленная таблица, даже если есть индексы. Особенно медленным будет удаление старых данных. Ты быстро повстречаешь деда "Вакуума". Да и просто удаление строк - это не быстро. А вот полное удаление таблицы (которая и есть представление одного парта) - это быстро и не вызывает "деда".

кирилл, я знаю про и вакуум и про партиции.. Это не ответ на вопрос.

в моем бы случае это решилось бы расширением hll, но его мне не поставить. оно не в white listе 😞

Ну твоя проблема "много данных" + "нельзя делать предагрегацию, что бы данных было меньше". Такое в постгре, кроме как патрицированием по моему ни как толком и не решается. Всё что я видел было именно через это.

кто сказал, что нельзя делать предагрегацию?

Ну ты сказал что данных много. Значит уже вариант предагрегации откинул, т.к. это первое что приходит в голову

Плюс произвольные периоды времени. А насколько произвольные? С точностью до дня или часа?

И тут ещё про таймзоны можно вспомнить, если это имеет значение.

Я когда то делал вот такую предагрегацию для уменьшения размера таблицы. Одна строка в таблице - это id метрики, год и array-поле куда добавлялись значения метрики (integer) по каждому дню в году.
Само собой была вторая таблица с сырыми "хитами", которая аггрегировалась раз в сутки и очищалась.

ну вот я подобное хочу сделать. Но посчитанная инфа за каждый день не позволит найти число уникальных юзеров за год. Для этого hyperloglog придумали, у него, помоему, можно мержить состояния.
Возможно можно обойтись и без этой магии, но я пока не знаю как.

А если в таблицу юзеров добавить array с годами, в которые этот юзер "засветился"? Не думаю что это поле будет большим. Ну лет 50 если проработает сервис без изменений - это уже круто.

Но если периоды буду совсем произвольные, то такое не прокатит

в принципе можно..
но в постгресе лучше ничего не обновлять. ибо в нем обновление это delete & insert. Со всеми проблемами деда вакуума.
плюс мне нужно гранулярити почаще чем раз в год.. ну и чтобы это всё работало, нужны индексы, которые совсем не бесплатные..

Ты писал что-то про то, что тебе бы подошёл HyperLogLog, но это расширешине не в белом списке. Вот ещё есть расширение для постгри - PipelineDB, там типа тоже есть эта штука (и другие "вероятнстные структуры").
Вот тут чувак про это обмолвился
https://youtu.be/3WkNp7mllv0?t=1960

Может тебе весь доклад будет интересен.

спасибо, но я ограничен auzrой

Кстати в докладе говорится о том что TimescaleDB очень дружит с Азурой. Но это расширение в основном про хранение time-series данных, там нет каких-то продвинутых функций для аггрегаций и вычислений, которые есть в PipelineDB