Melkij

Здесь по инструкции только под Postresql выделяется все 100% ОЗУ, такой конфиг подойдет разве что если на сервере будет только постгрес крутится и не более.

Именно так. Потому что вы читаете про highload. Под СУБД выделяется отдельный физический хост, плюс ещё парочка таких же под реплики. И уж явно не с механическим io. highload СУБД на HDD не бывает уже очень давно.

Проставьте оба конфига из расчёта 16гб памяти. Всё равно упрётесь в диски. Да и в CPU тоже упрётесь.
Если вы поставите shared_buffers в 25% ram, и innodb_buffer_pool_size в 80% - то у вас запустится банально только одна из баз. Ну или буфер перманентно в свопе будет, что в общем-то ещё хуже.
Кстати, надеюсь, вы по крайней мере проверяете смысл изменяемых настроек. Чтобы не было интересных сюрпризов вроде сделали всю базу на myisam, а крутите innodb_buffer_pool_size

Смотрите в оконные функции. lag и lead, в postgresql давно, в mysql в 8.0 наконец появились. Для более старых mysql - извращаться.

Зачем оно вам? Вот скажите, зачем? Пока ни один из встреченных адептов докера не справился с таким простым вопросом "зачем вам база в докере?", может вы справитесь.

Для использования базы вы обязаны предоставить нормальную файловую систему, необходимо предоставить сеть хоста. Изоляция? Так у вас система целиком под базу и так. Миграция на другой хост? Да у вас в этом докере только бинарники базы и есть. Точно такие же как в репозиториях, сама база-то снаружи в нормальной ФС. На другую архитектуру вы datadir не перетащите в принципе. Несколько кластеров баз на одной машине? А докер для этого зачем? На ubuntu/debian есть шикарные скрипты pg_ctlcluster. Про извращения с pg_upgrade обновлением базы не буду перепечатывать ответ с ruSO.

На взгляд postgresql dba вы не передали никаких настроек вообще, а work_mem и вовсе уменьшили, 4мб у него дефолт. Соответственно база будет работать по-умолчанию, т.е. из расчёта запуститься на любом калькуляторе, а не внятно работать. Не хватает, соответственно, всего. Настройки более агрессивных checkpointer, bgwriter и autovacuum в первую очередь.
По запросам смотрите pg_stat_statements

Минорные релизы именно так и ставятся: обновляются выполняемые бинарники и рестартовать базу в том же самом datadir.
О чём есть замечание в каждых release notes: https://www.postgresql.org/docs/9.6/static/release...

A dump/restore is not required for those running 9.6.X.

release notes стоит поглядеть для всех пропущенных апдейтов, могут быть важные замечания для обновления.

Кстати, обратите внимание, что 9.6.9 уже вышел и обновляться стоит именно на него.

Обычный union all.

select ... from a ...
union all
select ... from b ...

Можно сделать view.

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

Список нужных radio есть отдельно или надо искать по этой же табличке?
Если искать по этой же табличке - то вам нужен loose index scan. Глупый планировщик сам так делать не умеет, надо объяснять вручную.
Если список есть отдельно - то простой lateral join подзапроса будет компактнее.
Вот тут с 30 по 46 слайды

Необходим индекс btree(radio, date) если я верно понял по какому признаку вы хотите определять "последнее" значение.

Вы удалили предыдущий вопрос и у меня нет желания набирать ответ повторно. Поэтому буду краток.
На одну ошибку указал Rsa97 , вторая ошибка:

SELECT id FROM Users;
SELECT id FROM "Users";

Это обращения к разным таблицам.

Разберитесь, где вы потеряли сами сообщения об ошибках pg.

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

Возьмите pgq и пишите в очередь перед коммитом как найти нужные данные. Или триггером сразу при записи в таблицы шлите сообщения через pgq.
При экспорте соответственно читаете сообщения из pgq. Всё.

Или напишите или возьмите какой-нибудь готовый logical decoding. Сможете читать вообще поток репликации

В общем случае в общем-то нужна всё равно очередь. Из транзакции в таблички очереди пишете метки какие данные изменились, читатель читает эту метки и получает все изменения независимо от времени коммита.

Не говорите никому пароль от роли владельца, и никто не сможет подключиться к этой БД.

Вы таки удивитесь.
Дефолтно база доступна всем пользователям. И даже есть права на создание объектов. Удалить таблицу сможет суперпользователь или владелец этой таблицы. А вот создать - кто угодно.

Поэтому в postgresql после создания базы необходимо отзывать дефолтные права:

create database newdb;
\c newdb
GRANT CONNECT ON DATABASE newdb TO newdb_user ;
REVOKE ALL ON DATABASE newdb FROM public;
REVOKE ALL ON SCHEMA public FROM public;
GRANT USAGE ON SCHEMA public TO newdb_user;

Если при create database указать owner - то выдавать ему права на схему public будет избыточно, но делать revoke таки необходимо.

Сходная ситуация с mysql.