Солнца тоже не было

Класс, прям как дома )

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

Никто не сталкивался с такими проблемами? Может быть есть решение?

Уже в кренг еду

Я тоже

Если что, сидим тут

знатоки SQL, сколько займёт такой запрос:

SELECT created_at, count(sc.created_at) AS events 
FROM (
  SELECT generate_series(min(created_at), max(created_at), interval '60 min') 
  FROM table1
) g(start_time) 
LEFT JOIN table1 t1 
  ON t1.created_at >= g.start_time 
  AND t1.created_at < t1.created_at + interval '60 min'
GROUP BY 1
ORDER BY 1;

если в table1 лежит миллион записей, а min(created_at) — год назад? (т.е. generate_series выдаст серию из 9k значений)

EXPLAIN?

Я близко 😇

AND t1.created_at < t1.created_at + interval '60 min'

Тут ошибка? Условие всегда выполняется. Наверное, имелось в виду:

AND t1.created_at < g.start_time + interval '60 min'

нет, запрос верный (но очень глупый), он считает количество записей, созданных в каждый час

SELECT created_at, count(sc.created_at) AS events 
FROM (
  SELECT generate_series(min(created_at), max(created_at), interval '60 min') 
  FROM table1
) g(start_time) 
LEFT JOIN table1 t1 
  ON t1.created_at >= g.start_time 
  AND t1.created_at < t1.created_at + interval '60 min'
GROUP BY 1
ORDER BY 1;

Ты хочешь посчитать сколько было событий за каждый час? Если тебе не нужны пустые интервалы с нулём событий, то такой запрос будет и короче и быстрее:

SELECT to_char(created_at, 'YYYY-MM-DD-HH') AS hour, COUNT(*) FROM table1 GROUP BY hour;

это не мой запрос, я нашёл его в логах постгреса и пытаюсь понять, как он мог повлиять на производительность БД

Но ведь условие после AND — это тавтология, оно всегда будет равно true для любого значения t1.created_at, значит, его можно выкинуть. А если его выкинуть, оставшееся условие становится ещё более странным. Перечитай моё сообщение внимательно.

Может он повлиял на производительность потому, что условие неправильное?

кстати да, точно

У тебя там считалось для каждого start_time число всех ивентов, которые произошли после, а не всех ивентов, которые попадают в промежуток 60 минут, естественно оно будет тормозить.

SELECT created_at, count(sc.created_at) AS events 
FROM (
  SELECT generate_series(min(created_at), max(created_at), interval '60 min') 
  FROM table1
) g(start_time) 
LEFT JOIN table1 t1 
  ON t1.created_at >= g.start_time 
  AND t1.created_at < t1.created_at + interval '60 min'
GROUP BY 1
ORDER BY 1;

Надо гонять explain на реальной базе, но у меня локально не очень результаты на таблице в тысячу записей:

 Sort  (cost=7886.89..7887.39 rows=200 width=16)
   Sort Key: (generate_series((min(table1.created_at)), (max(table1.created_at)), '01:00:00'::interval))
   ->  HashAggregate  (cost=7877.24..7879.24 rows=200 width=16)
         Group Key: (generate_series((min(table1.created_at)), (max(table1.created_at)), '01:00:00'::interval))
         ->  Nested Loop Left Join  (cost=63.86..7103.91 rows=154667 width=16)
               Join Filter: (t1.created_at >= (generate_series((min(table1.created_at)), (max(table1.created_at)), '01:00:00'::interval)))
               ->  ProjectSet  (cost=63.86..68.88 rows=1000 width=8)
                     ->  Aggregate  (cost=63.86..63.87 rows=1 width=16)
                           ->  Seq Scan on table1  (cost=0.00..56.91 rows=1391 width=8)
               ->  Materialize  (cost=0.00..66.18 rows=464 width=8)
                     ->  Seq Scan on table1 t1  (cost=0.00..63.86 rows=464 width=8)
                           Filter: (created_at < (created_at + '01:00:00'::interval))