Comments 2
У listen/notify, конечно, вагон своих особенностей (начиная с того что они принципиально не crash safe), но советовать вместо них, упирая именно на производительность обработки, наиболее топорную самодельную очередь в базе? Очередь в базе - известный антипаттерн, приводит к головной боли.
work mem же... Вот сначала совершенно верно написано "сколько памяти доступно каждой операции запроса", а потом приводится классический неверный совет делить поровну на max_connections. Неверный именно потому, что work_mem - это память на одну операцию. И то без учёта hash_mem_multiplier. Один сложный OLAP запрос может сожрать десятки work_mem. Поэтому выставляется в разумное значение и отслеживаются потребности. pg_stat_statements тот же пишет temp_blk_write_time и temp_blk_read_time. Вполне обычная ситуация, когда для OLTP части work_mem небольшой, десятки мегабайт, а для пользователей со всякими отчётами work_mem выставлен именно на пользователя побольше. Или в целом на отдельной реплике, куда не ходят на OLTP данными.
Странные советы. Даже непонятно, серьёзные они или издевательские.
Девять способов выстрелить себе в ногу с PostgreSQL