понял, завтра на пример поближе гляну, возможно там действительно лучше будет, чем написать в лоб с partition by. Пока проблему с ним я описал - почему-то жрет оч много места на диске

> По-моему, всегда, когда возникает мысль использовать  latetal — надо остановиться и ещё пару раз подумать.  Можэт, обойдётся?

О чём думать-то? ;) Для подобных задач это очень часто одно из лучших решений.

> Вообще, вычисление результатов во FROM – это какая-то сомнительная практика.

Совершенно нормальная практика, и LATERAL для этого, собственно, и предназначен.

> Уж лучшэ вложэнных selectов нагородить.

Почти наверняка нет.

Есть задача хранить повторяющиеся события в БД. Для этого, судя по всему, лучше использовать стандарт RRULE. Проблема в том, что нет возможности написать такой запрос, который вернёт N событий начиная с даты X по дату Y. В интернете предлагают такое решение - выбирать все события, у которых указан RRULE и уже на бэкенде формировать список событий, которые попадают под этот RRULE.
Как вам такой подход? Мне кажется, что он не очень масштабируемый - чем дольше будет жить приложение, тем больше будет событий с RRULE, тем больше будет SQL выборка, тем сложнее бэкенду будет её прогонять

Действительно, чем плохи LATERAL?

А можете поподробней? Что именно лежит в БД?

в БД лежит событие, у которого прописаны
1. RRULE вида FREQ=DAILY;INTERVAL=2
2. Дата начала повторяющегося события
3. Дата окончания повторяющегося события

мне нужно сделать такой запрос, который вернёт все ЭКЗЕМПЛЯРЫ повторяющегося события. Т.е. если событие повторяется каждый день и я прошу вернуть все события с 1го по 7е число, то мне должно вернуться 7 событий (хотя в БД лежит всего одна запись)

а что, есть какое-то расширение для работы с rrule?
я заинтересовался

на гитхабе есть решение для постгреса, но не очень понятно как им пользоваться

интересно, спасибо

судя по всему оно просто парсит rrule в набор timestamtz или чего-то вроде, вряд ли есть смысл с таким разбираться, проще самому реализовать

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

я бы делал примерно так: вот есть таблица, скажем, event, в ней поле, содержащее описание recurrency, да хоть в том же самом rrule формате.  к ней стыкуется таблица event_dates, на вставку/обновление в event вешаем триггер (или считаем коллекцию дат на бэкенде)
запросы делаем select e from event e join event_dates on e.id = ed.event_id where ed.date between :start and :end
ограничение будет то же, что и у этого расширения: нельзя задать неограниченный диапазон дат, нужно чтобы был указан либо until либо count

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

теоретически нет, а практически она есть  
в реальности нет сценария "посмотреть встречи, которые я назначил в календаре через 20 лет", если вы, конечно, не снимаете одну из серий "Теории большого взрыва", но и там это кончилось довольно предсказуемо 😊

ну да, я согласен

добрый день, подскажите в каком приложении можно сделать такую схему баз данных ?

powerdesigner например

всем привет! подскажите, что может быть причиной того, что Постгрес использует индекс и судя по Explain ожидает получить rows=1, а вот по факту выгребает actual rows = 145601. Vacuum analyze на таблицу прогонял и т.п. Не пойму почему он делает такое кривое предположение ...

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