вьюху сделать, у которой конечная дата будет на 10 лет вперед
имхо достаточно более чем

> Проблема в том, что нет возможности написать такой запрос, который вернёт N событий начиная с даты X по дату Y.

А почему возможности-то нет?
С некоторыми видами интервалов (месяцы, например) просто так не посчитаешь, но это, тем не менее, возможно, или я чего-то не вижу?

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

Прямо написать функцию или (под)запрос, который возвращает "N событий начиная с даты X по дату Y", и использовать...

Покажите план запроса, хотя бы...

что бы написать функцию, потребуется парсить, а значит реализовать весь стандарт RRULE 😩

Это же Вы написали "Для этого, судя по всему, лучше использовать стандарт RRULE."
Может, не лучше (может, хватит чего-то попроще)?

хмм, подумаю в этом направлении, спасибо.
видел ещё такое решение https://stackoverflow.com/a/5186095/2247854

но я не очень понял, как это работает и работает ли

RRULE хорош тем, что это протестированный стандарт +  есть разные библиотеки под него. Например, есть библиотека, которая генерирует RRULE из строки "every second monday at 2pm"

Dbwrench

Вспоминаю, как со вздохом думал, что назначить самоподписанному CA expire date в 10 лет оказалось не самой удобной идеей...

('day', '11:30:00'::interval, '01.01.2021'::timestamp, '31.12.2021'::timestamp) — я бы как-то так хранил будильник

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

спасибо, обдумаю этот вариант тоже

Индекс по profile_id, create_ts desc есть? Если есть, то я ожидал бы, что запрос с row_number() over(partition by profile_id order by create_ts desc) не будет создавать временные файлы, все строки после 10-ой в каждой партиции будет просто пропускать

Индексов действительно нет, как-то я даже не связал одно с другим, хоть и пялился на explain, где seq scan написано :)

WindowAgg  (cost=3032.60..3648.46 rows=30793 width=24)
  ->  Sort  (cost=3032.60..3109.58 rows=30793 width=24)
        Sort Key: profile_id, create_ts DESC"
        ->  Seq Scan on payment  (cost=0.00..736.93 rows=30793 width=24)

Попробую добавить индексы, спасибо большое!

Единственно вопрос - а откуда можно узнать, что он временные файлы при индексах создавать не будет? Может, статья в доке? (в window functions не нашел) Или это какая-то общеизвестная вещь?

Я просто представил себе, как на низком уровне выполнять тот запрос, что вы желаете. Если индекса нет, то придётся всю таблицу в память и сортировать. А если есть, то можно по нему идти. Вовсе не уверен, что PostgreSQL умеет такую оптимизацию, но технически она возможна.

а, слушайте, а индекс-то есть похоже... не туда смотрел

Фильтра про row_number() <= 10 в плане я не вижу, это был план запроса с фильтром?

Возможно, я что-то не так делаю

Вот полностью запрос:

SELECT id
FROM (select id, row_number() over (partition by profile_id order by create_ts desc) as pos from payment) AS partition
WHERE partition.pos <= 500;

вот полностью explain:

Subquery Scan on partition  (cost=3032.60..4033.37 rows=10264 width=8)
  Filter: (partition.pos <= 500)
  ->  WindowAgg  (cost=3032.60..3648.46 rows=30793 width=24)
        ->  Sort  (cost=3032.60..3109.58 rows=30793 width=24)
              Sort Key: payment.profile_id, payment.create_ts DESC"
              ->  Seq Scan on payment  (cost=0.00..736.93 rows=30793 width=24)

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

попробуйте ещё сверху добавить order by profile_id, create_ts desc — это может подтолкнуть к использованию индекса