Делают кому как удобно. При хранении ссылок сразу страдает ссылочная целостность. Если файл удалят с диска вы об этом без костылей не узнаете. Мне больше нравится lobject. Файлы сразу кладутся на диск, минуя таблицу TOAST. Бьются на чанки, и права на них можно назначать без геморроя с RLS. Также нет ограничения на размер записи (для поля bytea он есть). На тестах работает раза в 4 быстрее, также быстро как mongodb на файлах на том же железе. Большинство адаптеров умеют работать с lobject, т.к. под капотом почти всегда libpq.

а как же размер бэкапа?

Можно BLOB бэкапить отдельно. И при бэкапе в формате директории (-Fd) каждый файл складывается отдельно. Очень удобно.

pg_probackup делает копию кластера ПОЛНОСТЬЮ, насколько я понимаю.

т.е. время создания бэкапа и время восстановления копии, а если это еще где то лежит в сетевом хранилище плюс время на сеть.

А зачем бэкапить весь кластер?
Как вариант - поиграться с tablespace.

потому что он так работает.

Холиварная тема. И Дмитрий прав - при храении файлов в отдельном месте - важен порядок бэкапа файлового хранилища и БД - чтобы в БД небыло битых ссылок - сначала резервируется она, потом хранилище - чтобы в случае отката иметь лишние файлы, но не битые ссылки. При хранении в БД такой проблемы нет. Но есть проблемы с резервным копированием - бэкапы становятся огроменными.

и восстановлением. И созданием реплик)

Приветствую. Может кто решал уже такую задачу.

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

Я бы решал так:
1) сджойнил бы таблицу саму на себя, тем самым получив перемножение строк, исключив пары из одной и той же строки

2) отфильтровал бы пары, где интервалы пересекаются. это делается рядом условий между началами и концами интервалов (только надо помнить о граничных кейсах, например, вхождении одного интервала полностью в другой)

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

Generate_series посекундный

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

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

Не вариант, этот подход с высокой вероятностью даст ошибку

Локальный пик может не попасть

А нельзя для каждой минуты просто посчитать количество звонков, которые входят в эту минуту? :) Вроде бы не так уж и много получается проходов - 24*60 = 1440 сканирований таблицы логов (понятно, что логи нужно в таблицу переводить)

В один день было 300 звонков за день, а в другой - 100 за час

ок, можно для каждой минуты, входящей в диапазон между минимальным значением звонка в сутках и максимальным