ky0

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

Надо смотреть, как формируется этот список. В целом, это неоптимально - но допустимо.

Я правильно понимаю, что вы на каждый запрос поднимаете новый контейнер с инициализацией кластера? Напрасно.

Я бы смотрел в сторону "один пользователь (или даже запрос) - одна БД внутри постоянно работающей толстой СУБД". Ну и БД периодически ротировал с очисткой.

Если вы внимательно посмотрите на окончания, то поймёте, что они поддаются описанию довольно простым повторяющимся паттерном (особенно начиная со второго десятка).

Первое, что приходит в голову - разделить домен и URI. Тогда можно будет сначала поискать по индексу доменов, а потом уже эту выборку по урлу.

Для этого существует логирование медленных запросов - log_min_duration_statement.

https://www.postgresql.org/docs/current/runtime-co...

Потому что, если у вас всё в Докере, подключаться надо по имени контейнера, а не к локалхосту.

Винда, 1С, бэкап настроен скриптом из гайда - сошёлся весь пасьянс. Что могло пойти не так?

Гарантированно консистентный снимок большой базы лучше делать с помощью реплики с задержкой применения изменений и архивирования WAL. А холодный бэкап делать вдобавок.

См. напр. https://habr.com/ru/companies/slurm/articles/445446/

"sql в перемешку с бинарём" - это скорее всего стандартный формат (pg_dump -Fc). Он сжат, поэтому вам кажется, что всё в перемешку.

Что происходит, если попытаться его восстановить с помощью pg_restore?

pg_dump -> pg_restore/psql -f

Права можно выдать и для ещё не существующей схемы.

То, что у вас в конфиге закомментировано - не просто так, а проверка работоспособности СУБД. Иначе оба контейнера стартуют одновременно и Постгрес не успевает подняться. То же самое без внешних скриптов реализуется с помощью depends_on + healthcheck.