Да, fsync=on. Посмотрю что будет если этот параметр так же перевести в off. В инструкции сказано, что Во многих случаях отключение synchronous_commit для некритичных транзакций может дать больший выигрыш в скорости, чем отключение fsync, при этом не добавляя риски повреждения данных.. При этом synchronous_commit = on, так что и с этим параметром можно поиграться.

В конфигурационном файле log_statement стоял 'none' или 'ddl'. Но все равно шли ВСЕ ЗАПИСИ. Про *.auto.conf мало кто вспомнил, да и не лазит в тот файл никто (наверное).

Здесь я полностью согласен со всеми пунктами. Данные не критичные. Если будет сбой, то полетит все. После восстановления (это около 3-5 минут) данные качаются из Quik (с ММВБ биржи), так что заботится о сохранении данных вообще не нужно никоим образом.

Железо - Intel 3700 (4 ядра+4 виртуальных)+ 16Gb оперативка + 2 SSD (Samsung серии Pro [обычные ssd не супер скоростные]). На одном SSD стоит основная машина, на втором SSD виртуальная машина с Windows 7 (4 ядра+4Гб) + на том же SSD стоит Debian (последний) (4 ядра + 3Гб).
При этом Debian нагрузить более 50% не удавалось никак, но при работе с pgAdmin сразу жрет оперативку. Без него 18% от 3Гб, а с pgAdmin 4 сразу 29% от 3Гб (то есть съедает сразу около 300Мб оперативки).
Использую VM VirtualBox.
Так что по оптимизации железа есть куда оптимизировать и потоки разделить и уйти с виртуальной машины, но пока это вообще никак не влияет на скорость работы.

По опыту скажу так. Сбои бывают 1-3 раза в год и для этих целей есть защитные методы (стопы, уровни и прочие технические нюансы при автоматической торговле на бирже).
Нагрузка в пики не более 20-45%, но это всего 5-7% от общего времени. В остальное время суммарная нагрузка около 5-12% (если замерять на основной машине, в которой запущено ВСЕ сразу).
При обычной торговле за 1 секунду проскакивает около 200-500 тиковых сделок, так что даже 5500 это уже с большим запасом.

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

Guzya,
Я на postgreSQL перешел вообще с Cache Inter Systems. Многие вещи были в диковинку. Только сейчас начинаю понимать что и как здесь работает. Но с непривычки все раскидано по разным местам и слишком много всяких настроек, но зато СКОРОСТЬ ПОРАЖАЕТ!.
Многое то что описано в официальной инструкции ну никак не воспринимается, даже тот же самый postgresql.conf ведь он очень подробно расписан, а вот про *.auto.config читал, залазил туда, но в памяти не отложилось (но точно не правил).

В общем, БД шикарная, может много чего, скорость поражает, но реально для её изучения (по 3-7 часов в день) требуется не менее 6 месяцев. Я с октября в ней сижу (когда больше, когда меньше) и только благодаря книге PostgreSQL 11 (Ганс-Юрген Шёниг) стал двигаться быстро - там многие заумные вещи написаны на понятном для людей языке. Хотя может достиг критической массы для начала реального изучения.
Остальные книги или копия официальной инструкции или сразу уже для профи (тот же PostgreSQL 10 от Салахалдин Джуба и Андрея Волкова).
В общем оно того стоит, впечатления от работы БД только самые положительные.
.