А как? есть готовые гайды?

при старте postgres базы выдает ошибку:
could not access file "pg_cron": No such file or directory
но pg_cron установлен.
подскажите в чем проблема

Всем привет!

(Просто заметил в логах чата).
Для Вас и @AntsiferovMaxim :
Правильно генерация именно дат (а timestamptz)  делается вот так:

SELECT g.d::date
  FROM generate_series('2020-01-01'::timestamp, '2020-05-01'::timestamp, '1 day') AS g(d)

Хотя ошибка тут крайне маловероятная, лучше всё-таки использовать и распространять правильный вариант, IMHO.

А тут можно задавать вопросы по запросам? :)

В принципе, да.

Вообще хотел уточнить один момент, может быть кто-нибудь сможет подсказать. Занимаюсь анализом данных, поэтому решил погрузиться в sql, чтобы прокачать навыки работы с БД. Изучил на datacamp и джоины, и всякие union'ы и подзапросы с оконками. Но я никак не могу понять, в каких случаях лучше применять подзапрос, а в каких лучше обойтись джоином и т.д.

Неужели нет каких-то негласных правил, которые говорили бы, что в таких случаях лучше идти через джоин, а в таких через оконку и т.д.?

Может быть есть какие-то нормальные материалы на эту тему, которые можно было бы изучить?

Вообще получается, что в голове каша и когда видишь задачку вроде: Find the number of Employees of each role in the studio

ты не знаешь, как её решить, потому что в голове бардак

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

Те, выяснить, каким образом можно решить данную задачу вообще.

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

При альтернативе “join vs подзапрос” нужно выбирать джойн, потому что подзапрос - зачастую препятсвие для оптимизатора для того, чтобы построить более выгодный план и выполнить запрос быстрее.

Про альтернативу “join vs window functions” я не слышал, все же у них разное предназначение.

По идее, любой возможный запрос с window functions на корректно нормализованной базе можно написать без них (как раз с помощью JOIN, в том числе), "классически". Т.е. именно в плане возможностей (написать то, что без них было бы невозможно) window functions не добавляют почти ничего.

И мне лично это мешает иногда — в тех случаях, когда кажется, что какой-то запрос можно написать с их помощью, а потом  думаешь / пробуешь — нет, нельзя (и вот они JOIN-ы). ;)

16 памяти, 8 ядер. shared_buffers 6gb, work_mem 4mb, max_connections 300

просто хочу понять, это нормально или нет что 1 очень тяжелый селект выжирает диск на read на 100%?

Почему бы и нет? Если данных нет в shared_buffers и в page cache операционки, то поднимать их в память используя диск на 100% гораздо быстрее чем использую его на 5-10%