Ага

Ну я типа PoC сделал

OVER ( PARTITION BY request_id ORDER BY timestamp ASC) AS next_action, LEAD(timestamp, 1, timestamp) OVER ( PARTITION BY request_id ORDER BY timestamp ASC) AS next_timestamp ты вот уверен, что это правильно написано?

А почему нет? Я на бумажке посчитал, функция тоже самое выводит

2-й и 3-й аргументы явно объявлены чтобы убрать NULL значения когда заканчивается временной ряд интервалов

Таким образом next_timestamp будет равен timestamp и его разница будет равна нулю

ну я как-то совсем не уверен

Так а что тебя конкретно смущает? Я проверю

а оконные фукнции для PG надо вспоминать, я не знаю их так хорошо.

Меня смущает, что нет никакого значения.

OVER ( PARTITION BY request_id ORDER BY timestamp ASC) AS next_action вот поле, вычисляемое оконной функцией. А ГДЕ то, что собственно берётся за значение ?

Так LEAD же

Первый арг

В первом случае там action следующей строки, а второй LEAD это timestamp следующей строки

Цифровые пары ­— это возможные переходы (валидные) состояния которые надо затрекать (суммировать)

SELECT depname, empno, salary, avg(salary) OVER (PARTITION BY depname) FROM empsalary;

представь как все было бы проще если просто прочитал посчитал проапдейтил сумма выбирается автоматом

вот пример валидного запроса с оконной функцией.

но тут явно не нужно проще.

вот пример валидного запроса с оконной функцией.

Ну у меня вместо avg(salary) — lead(action, 1, action)

вот пример валидного запроса с оконной функцией.

а, нет, я неправ, всё ок

Тебя видимо 3 аргумента для оконной функции с толку сбило?

Я там просто там от NULL значений избавился и все

Это был самый простой способ

представь как все было бы проще если просто прочитал посчитал проапдейтил сумма выбирается автоматом

Ну а сейчас просто "вставил в базу", "you are awesome"

Плюс архитектура append only мне нравится куда больше

Ну а сейчас просто "вставил в базу", "you are awesome"

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

Тебя видимо 3 аргумента для оконной функции с толку сбило?

Я разобрался.

Ну подожи, какой бизнес кейс у удаления в трекере?

Это как какахи пальцами из попы начать вытаскивать

А EXTRACT(EPOCH FROM (next_timestamp - timestamp))) что делает?

И кстати, даже если мне надо что-то поменять то замена будет только одной записи по pk

Кол-во секунд итоговое

Кол-во секунд итоговое

гыыыы. то есть в твоем представлени примерно так "время занимает только отправка запроса, база ЛЮБОЙ запрос обрабатывает МНОГНОВЕННО"

Ну ладно, главное-то не это всё, а запустить этот запрос и получить данные. И проверить, насколько быстро СУБД его выполняет. Тут если сделать индекс по (request_id,timestamp) потенциально это может работать быстро. Если будет, ок, можно и так оставлять. Если нет — надо сначала выгрызать данные

гыыыы. то есть в твоем представлени примерно так "время занимает только отправка запроса, база ЛЮБОЙ запрос обрабатывает МНОГНОВЕННО"

Ну нет же. Это надо для биллинга (точный расчет) и при первой загрузке трекера, дальше оно JS'ом

Кол-во секунд итоговое

экстракт ЭПОК из даты — получаются секунды?

Ага, такой вот постгрес

Ну нет же. Это надо для биллинга (точный расчет) и при первой загрузке трекера, дальше оно JS'ом

ой все.. хорош. я уже под столом. продолжай. это еще и билинг гыыы

Ну ладно это в общем не важно

экстракт ЭПОК из даты — получаются секунды?

так оно ж всю таблицу перелопачивает

так оно ж всю таблицу перелопачивает

Где всю то? Вы план запроса можете составить в уме?

Там выбрка идет по owner_id, request_id сначала

Ну нет же. Это надо для биллинга (точный расчет) и при первой загрузке трекера, дальше оно JS'ом

Ну и гляди, ты тут жёстко прописываешь пары предыдущая -следующая запись. Типы событий. А ВДРУГ они не такие ?

Высекается ну максимум в худшем случае для наркоманов 50 записей

Ну и я бы НЕ ПИСАЛ оконку, взял бы просто self-JOIN.

Ну и гляди, ты тут жёстко прописываешь пары предыдущая -следующая запись. Типы событий. А ВДРУГ они не такие ?

Как они могут оказаться не такие?

Я конечно всякого в базе повидал, понимаю о чем ты но все же

Как они могут оказаться не такие?

Да хрен знает... НУ, ПОТЕРЯЛОСЬ....

?

Значит в этом случае я буду тем парнем из авито

Который отключает fsync в PG ради скорости вопреки риску потери данных (какой-то части)

Т.к. это будет дешевле восстановить с точки зрения бизнеса через саппорт

Ладно, я полагаю, что вопрос исчерпан, если ты добьешься от этого запросика приемлимой производительности (или другой напишешь), То и ОК, если нет — думаю, тебе надо БЕЖАТЬ ВВЕРХ И ВЫДЕЛЯТЬ ЦЕПОЧКИ СОБЫТИЙ. Я вот лично по таким подобным задачам ВСЕГДА в конце приходил к тому, что выделял.

Значит в этом случае я буду тем парнем из авито

Это ты к чему?

Это ты к чему?

Ну в Авито DBA отключают на дисках fsync чтобы PG быстрее работал

Дает им прирост скорости

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

И вот этот проеб данных последние Х-минут восстановить через саппорт дешевле чем купить 10 новых серверов для PG (условно) чтобы покрыть прирост произовдительности когда они вырубили fsync

Звучит дико )

Ну в Авито DBA отключают на дисках fsync чтобы PG быстрее работал

Это я понял.

А, ну это я к тому, что если цепочка внезапно разломается

Значит в этом случае я буду тем парнем из авито

В КАКОМ случае?

И какой-то интервал не забиллится

А

ERROR: S client not available

Мы просто возьмем и руками его восстановим )

ну ок

AI наверное плачет )

Ладно, теперь реально сложный вопрос

Кто-нибудь делал расписания в базе? Как хранить "два-через-два"

Логику прописывать.

никаких секретов

Логику прописывать.

нене. погоди. мы кажется нашли того мистического говнокодера который делает что то потому что ему понравилось написаное в статье а не то что реально подходит под его задачи

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

И туда "два-через-два" никак не сохранить

ОПисываешь правила типа ДВА ЧЕРЕЗ ДВА, делаешь календарь, запоняешь его на скажем год вперёд, применяешь правила, которые к этому календарю что-то привязывают. И уже в фиксированных датах намечаешь события.

Может есть бест-практис схемы?

нет. ТЗ у всех разные. НЕ бывает общих

Т.е. основной посыл — заполнять на год вперед?

можно не на год

Эта пре-генерация довольно straightforward так сказать

Мне бы опять же без пред-заполнения

суть в том что у тебя будет N разных типов правил. ТИпа как иерархия объектов в ООП, Каждое будет там как-то находить времена вычислять и привязываеться к конкретным датам. полиморфно на этой иерархии правил

Мне бы опять же без пред-заполнения

Ну а как ты правила эти без предзаполнения, типа КАЖДЫЙ ВТОРОЙ ДЕНЬ а откуда второй ?

Ну вот схему такую и сделать

Перелопачивать календать на полгода из пользовательского интерфейса это как то не оч

Ну как бы и по логике предметной области все эти правила они как бы декларативные. но всё равно можно и как бы императивно всегда назначить что-то на вполне определённое время.

Перелопачивать календать на полгода из пользовательского интерфейса это как то не оч

Почему из пользовательского ?

Короче я запарился объяснять домой хочу.

Ну вот пользователь заходит в календать и там херовина "Два-через-два"

Не буду же я добавлять в базу записей на полгода сразу )

А если он передумает? Удалять?

Тлен

Хочешь делай, не хочешь — думай сам. Я такое делал раза три наверное, удобно, логично, производительно

Не буду же я добавлять в базу записей на полгода сразу )

Почему нет?

полгода это вшивых 180 записей