Всё что нужно, чтобы передать данные с приложения на СУБД - это никогда не смешивать данные и управляющий этими данными SQL-запрос. Prepared statemenets, то есть.
А вы не можете пробросить устройство в контейнер. Вообще не можете.
Потому что у контейнера нет своего ядра, некому управлять устройством внутри контейнера. Устройством управляет ядро хост-системы.
> Простейший запрос не работающий с данными таблиц:
... не использует ни shared_buffers, ни другие ваши настройки. Только чистый work_mem - максимум памяти для одной сессии. Скромных 10мб для quicksort на 25кб более чем хватает.
Ну и с чего бы pg выделять много памяти? Хотя shared_buffers выделяются персистентно. Поэтому и вопрос к тем методам, которыми вы оцениваете потребление памяти и рестартовали ли pg после изменения объёма буфера.
Кстати, чтобы не нервировать зря mysql я сделал фейковую табличку, скопировал с неё frm, удалил эту табличку, потушил mysql, подсунул frm и запустил mysql обратно.
Только что проверил на mysql5.7, для удаления таблицы не имеет значения, от какой таблицы frm. Подсунул чужой frm, drop table сделать получилось и затем новый create table уже успешен. Иначе, похоже, без dump/restore не обойтись. stackoverflow.com/a/26981438
Вот что за неуважение? Сами пишете, что не понимаете работу банальнейшего join - и тут же жмёте "пригласить эксперта". Зачем вам срочно эксперт понадобился? Откуда вам заранее знать, что это вопрос уровня эксперт, а не любого мимопроходящего пользователя?
"сейчас окажется, что где-нибудь в прикладном ЯП типа PHP с отключённым отображением ошибок". Ну вот а я о чём? Какой-то PHP и, естественно, с отключенным выводом ошибок. Распечатайте весь fetch_assoc и посмотрите, какой ключ полю присвоен в реальности.
