Можно вопрос: а каким образом, это вообще может сказаться на производительности ?
PostgreSQL не все равно, откуда пришли запросы, на которых он "лег" ?

подскажи о добрый человек, куда мне дописать пару строчек чтоб оно работало не на 600 запросов а хотя бы на 6000? ведь это же просто. как в стековерфлоу - ктрл-ц ктрл-в и всё работает. ведь это же так просто исходя из твоих слов?

Oracle - действительно просто, в init.ora надо добавить fast = true, к сожалению PostgreSQL значительно отстал в развитии

сначала определяют, чего именно не хватает СУБД и что конкретно потребляет ее ресурсы

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

если есть подозрение, что "тяжелые" это insert и commit, смотрять статистику по записи на диск и время ожидания фонового процесса сброса грязных буферов и лог врайтера, насколько часто и безболезненно проходят чекпоинты (терминология у меня хромает, но postgresql вроде один в один Oracle 8i). Чем грязных буферов больше, а сбросов/чекпоинтов меньше, тем быстрее работает

думают, можно ли проапгрейдить железо или поменять параметры (для Oracle например размер redo log buffer и время до чекпоинтов / размер redo log файлов, с PostreSQL сложнее и не настолько явное влияние оказывает afaik)

если диски HDD, то крайне осмысленно/желательно вынесение redo log на отдельные диски и вынесение на отдельные диски redo log archive, что бы при архивирование redo log была минимальная конкуренции с текущими транзакциями

и так далее и тому подобное

зная, что конкретно "плохо", можно уже думать, как это плохо убрать

IMHO

п.с. под PostgreSQL есть еще такая вещь, как Vacuum, но ее ни разу не пытался тюнить / настраивать, не сталкивался

в config.sys добавить:

fast_insert = true
no_lock_mode = true

в autoexec.bat

smartdrv.exe c+