не отменяет того, что resultset — термин.

у массива порядок может и определен, а у result set-а, который возвращает функция?

unnest же функция, а не массив

Термин. Но, возвращаясь к первоначальному вопросу:

> select … from unnest(…) with ordinality вот в этом случае будет ли ordinality совпадать с порядком элементов в массиве?

Как видите, некоторые считают, что из:

If the WITH ORDINALITY clause is specified, an additional column of type bigint will be added to the function result columns. This column numbers the rows of the function result set, starting from 1. (This is a generalization of the SQL-standard syntax for UNNEST ... WITH ORDINALITY.) 

такой вывод (что всегда будет) не следует. Т.е. документация PostgreSQL написана неоднозначно / непонятно.

подскажите, кому-то приходилось хранить в БД повторяющиеся события? Как это сделать по-умному?

Надо учитывать, что
- События могут повторяться по сильно специфичным правилам типа "каждый второй вторник", "каждый понедельник, вторник и среду"
- Надо построить запрос, который будет выбирать эти события по дате . Например, если я прошу выбрать события, которые будут проходить с 10 по 17 число, то нужно отобразить и те, который были созданые первого числа, но повторяются каждую неделю (в т.ч. и с 10 по 17 число)

А вы хотите хранить только дату начала, дату окончания и расписание?

да. Т.е повторяться события могут до 2040-го года, нельзя же их все сразу хранить в БД

Ну смотря сколько событий

смотря с какой глубиной

ну их может быть бесконечное количество, если дата окончания не задана. Как в гугл календаре.

Ребят, вопрос по поводу wal_sender_timout. Допустим у меня есть питоновский клиент который умеет поглощать оплоги постгреса, алгоритм его работы такой:

1. подключается к мастеру под заранее заданный слот
2. съедает сколько-то логов, максимум до 3500 секунд
3. преобразует и загружает эти логи в S3
4. адвансит свой слот репликации на мастере только когда логи успешно загружены в S3
5. закрывает подключение к мастеру

Питоновский клиент репликации держит коннект открытым, и пункт 3 может иногда занять довольно много времени. Когда тут начинается отсчет wal_sender_timeout, с момента поглощения последнего лога?

Тут варианта 2:
1. Хранить каждое наступление события, генерировать их не на весь срок, а вперёд на пару месяцев (или на сколько требуется), в остальном - работать как с независимыми. При этом, правила формирования расписания могут быть любыми (например - каждая третья секунда каждого четного часа по понедельникам и четвергам). Если требуется дополнительно хранить историю исполнения расписания, то такая схема получает преимущество (не нужна отдельная таблица для исполнения).
2. Хранить дату начала и окончания + расписание в формате индексируемой структуры (такой, чтобы можно было по индексу отобрать записи, которые нужно выполнять в определённое время или в определённый интервал), тут придётся думать, как конкретно хранить и запросы для отборы конкретных планируемых запусков будут сложнее. Требование индексирования накладывает ограничения на возможности расписания. (либо придётся строить упрощенную версию расписания, которую можно будет проиндексировать)

Понял, спасибо. В интернете нагуглил что надо делать отельную страницу для правил и уже по ней выбирать события, но вот как именно выбирать - я не понял

Я бы поделил неделю на часы (меньшая гранулярность сильно раздует индекс) и построил бы индекс, по полю, которое будет заполняться таким образом, чтобы гарантированно содержать все возможные часы запуска данного расписания. Такую структуру можно будет проиндексировать (например, как intarray).

ну т.е. хранить каждый экземпляр события?

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

Либо идти от каждого типа правила:
- находить периодичность (если есть)
- заполнять значения внутри периодичности
- брать дату начала события
- прицеплять к ней полученную матрицу с учетом периодичности
По идее для каждого типа своя процедура или что-то типо того...

Нет, хранить маску часов недели, в которые расписание может быть исполнено. По такой маске можно будет индексировать.

тяжко

Но все-таки сначала оценить масштаб проблемы - может проще генерировать полное расписание с некоторой глубиной