А как она оказалась там (и сохранность тут ни при чём, кстати, и даже для PostgreSQL), я пропустил?

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

Именно так

нарезали в tmpfs 100Гб+, директория postgres там

Блин, ну ON labels.name = другому столбцу в другой таблице можно нагуглить?

Небольшая подсказка: у вас нет условия связывания таблиц между собой. Поэтому погуглите.

Да прекратите Вы это, а?
Это точно не "наша" СУБД, и всё это — off topic.
Можете спросить в @sql_ninja (говорят) или в https://t.me/dba_ru

MySQL HandlerSocket ?

Вы бы лучше просто взяли эту планку памяти и выкинули её, честное слово. :(
Причиной подобных "блестящих" идей обычно является полное непонимание того, как современная СУБД работает с RAM.
Тут где-то в чате это "разжёвывали" — поищите в истории.

мб оно, да

это вы так зря сделали, бесмысленно и бесполезно.

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

HL - это 10Ktps, 100Ktps, 1Mtps?

Нет, причина именно эта — тот, кто это сделал, поступил https://t.me/pgsql/283954
Т.е. лучше не стало, стало хуже. Я вполне серьёзно написал то, что написал выше.

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

кстати, может подскажет кто.. я так и не нашел вменяемого механизма получения статистики по запросам - в mysql можно получить число запросов/сек, в postgresql - какие-то xact_commit, xact_rollback(что не равно qps) и всякие tup_deleted, tup_fetched, tup_inserted, tup_returned, tup_updated

pg_stat_statements

Оно чё-то померло. Слишком сложно

крутил тоже.. сильно грузит, в tmpfs вроде как нужно выносить?

Да-да. Только вот если бы сделали, как я написал, работало бы не хуже.

> мне самому было интересно разобраться

Вот и разбирайтесь, а не верьте безумно идиотским "мифам", и тем более, не внедряйте их. ;(
Если Вам действительно интересно, почему это так — см. историю чата (или достаточно вспомнить, как СУБД работает с RAM, и подумать, какие будут последствия того и другого варианта). Если уж совсем не верите — разверните тестовый сервер да и сравните.