Приветствую Вас, уважаемые!
Столкнулись с такой проблемой – DESCTOP компьютер работает быстрее сервера. В нашей организации в данный момент под СУБД используется комп с процессором I7, 16 Гб ОЗУ, ОС –AstraLinux. Операционка стоит на HDD, база на SSD, причем pg_xlog на отдельном SSD диске. Сама база размером 120-150 Гигов. Postgresql версии 9.3.4
Настройки Postgresql следующие:

listen_addresses = '*' # what IP address(es) to listen on;
port = 5432 # (change requires restart)
max_connections = 400 # (change requires restart)
unix_socket_directories = '/var/run/postgresql' # comma-separated list of directories
shared_buffers = 4096MB # min 128kB
temp_buffers = 32MB # min 800kB
work_mem = 64MB # min 64kB
maintenance_work_mem = 2048MB # min 1MB
max_stack_depth = 2MB # min 100kB
effective_io_concurrency = 1 # 1-1000; 0 disables prefetching
wal_level = minimal # minimal, archive, or hot_standby
fsync = on # turns forced synchronization on or off
synchronous_commit = on # synchronization level;
checkpoint_segments = 64 # in logfile segments, min 1, 16MB each
checkpoint_timeout = 50min # range 30s-1h
checkpoint_completion_target = 0.9 # checkpoint target duration, 0.0 - 1.0
checkpoint_warning = 59s # 0 disables
effective_cache_size = 10240MB
constraint_exclusion = partition # on, off, or partition
log_destination = 'syslog' # Valid values are combinations of
log_timezone = 'W-SU'
autovacuum = off # Enable autovacuum subprocess? 'on'
bytea_output = 'escape' # hex, escape
datestyle = 'iso, dmy'
timezone = 'W-SU'
lc_messages = 'en_US.UTF-8' # locale for system error message
lc_monetary = 'ru_RU.UTF-8' # locale for monetary formatting
lc_numeric = 'ru_RU.UTF-8' # locale for number formatting
lc_time = 'ru_RU.UTF-8' # locale for time formatting
default_text_search_config = 'pg_catalog.russian'
max_locks_per_transaction = 150 # min 10
online_analyze.threshold = 50
online_analyze.scale_factor = 0.1
online_analyze.enable = off
online_analyze.verbose = off
online_analyze.min_interval = 10000
online_analyze.table_type = 'temporary'
plantuner.fix_empty_table = true

В дальнейшем предполагается большой рост базы поэтому был куплен следующий сервер: system x 3850X6, два процессора Xeon E7-4860 2.60Ghz по 12 ядер в каждом, ОЗУ 256 Гб, Операционка стоит на SSD, база временно лежит на двух SSD в RAID0. В дальнейшем база будет лежать на СХД. Настройки Postgresql следующие:

listen_addresses = '*' # what IP address(es) to listen on;
# comma-separated list of addresses;
# defaults to 'localhost'; use '*' for all
# (change requires restart)
port = 5432 # (change requires restart)
max_connections = 400 # (change requires restart)
shared_buffers = 32GB # min 128kB
temp_buffers = 1GB # min 800kB
work_mem = 500MB # min 64kB
maintenance_work_mem = 64MB # min 1MB
max_stack_depth = 7680kB # min 100kB
effective_io_concurrency = 1000 # 1-1000; 0 disables prefetching
wal_level = minimal # minimal, archive, or hot_standby
fsync = on # turns forced synchronization on or off
synchronous_commit = on # synchronization level;
checkpoint_segments = 32 # in logfile segments, min 1, 16MB each
checkpoint_timeout = 50min # range 30s-1h
checkpoint_completion_target = 0.9 # checkpoint target duration, 0.0 - 1.0
checkpoint_warning = 59s # 0 disables
constraint_exclusion = partition # on, off, or partition
log_destination = 'stderr' # Valid values are combinations of
logging_collector = on # Enable capturing of stderr and csvlog
log_connections = off
log_disconnections = off
log_statement = 'all' # none, ddl, mod, all
log_timezone = 'W-SU'
autovacuum = off # Enable autovacuum subprocess? 'on'
bytea_output = 'escape' # hex, escape
datestyle = 'iso, dmy'
timezone = 'W-SU'
lc_messages = 'en_US.UTF-8' # locale for system error message
lc_monetary = 'ru_RU.UTF-8' # locale for monetary formatting
lc_numeric = 'ru_RU.UTF-8' # locale for number formatting
lc_time = 'ru_RU.UTF-8' # locale for time formatting
max_locks_per_transaction = 150 # min 10
online_analyze.threshold = 50
online_analyze.scale_factor = 0.1
online_analyze.enable = off
online_analyze.verbose = off
online_analyze.min_interval = 10000
online_analyze.table_type = 'temporary'
plantuner.fix_empty_table = true
Для теста на новый сервер pg_dump’ом перенесли базу на новый сервер, позупаскали запросы. И тут ждало огромное разочарование – новый дорогой сервер оказался медленнее DESCTOP компьютера. И чем тяжелее запрос тем разница больше.
Для подтвержения вывод pgbench:
1. DESCTOP

pgbench pgbench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1000
query mode: simple
number of clients: 1
number of threads: 1
number of transactions per client: 10
number of transactions actually processed: 10/10
tps = 710.126402 (including connections establishing)
tps = 797.193878 (excluding connections establishing)
postgres@C3ZB1A7A1:/root$ pgbench pgbench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1000
query mode: simple
number of clients: 1
number of threads: 1
number of transactions per client: 10
number of transactions actually processed: 10/10
tps = 632.991518 (including connections establishing)
tps = 710.580544 (excluding connections establishing)

select count(*) from pgbench_accounts
Первый запуск - 14.000 мс
Второй запуск - 12.653 мс

2. Server
pgbench pgbench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1000
query mode: simple
number of clients: 1
number of threads: 1
number of transactions per client: 10
number of transactions actually processed: 10/10
tps = 495.245642 (including connections establishing)
tps = 582.072177 (excluding connections establishing)
postgres@C3UH8A1A2:/root$ pgbench pgbench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1000
query mode: simple
number of clients: 1
number of threads: 1
number of transactions per client: 10
number of transactions actually processed: 10/10
tps = 459.748977 (including connections establishing)
tps = 560.695262 (excluding connections establishing)

select count(*) from pgbench_accounts
Первый запуск - 11.713
Второй запуск 11.343

Я в «тихом» шоке. Уважаемые знатоки, подскажите в чем может быть проблема?

Еще раз, добрый день!
Постараюсь ответить все. Значит:
autovacuum в значении off, потому что "vacuum alalyze" выполняется по cron 4 раза в сутки.

"А какой смысл 24 ядерный сервер тестировать в 1 поток?
Скорость работы 1 ядра у серверных процессоров уже давно абы не медленнее чем у обычных персоналочных.
"
А если много сессий только делают Insert, и только одна сессия Select (для отображения). Или расскажите как один select разбить на несколько потоков?

На I7 тактовая частота 3,2 Ггц, а у E7 2,6Ггц. Но в Е7 кэши всех уровней больше чем в I7 -не ужели это ни какой роли не играет?

Так же хочу выложить план запроса.
Для DESCTOP
Result (cost=1.20..51679.28 rows=628467 width=56)
InitPlan 1 (returns $0)
-> Seq Scan on dic_colors dic (cost=0.00..1.20 rows=1 width=8)
Filter: (colors_id = 2)
-> Append (cost=0.00..42251.08 rows=628467 width=56)
-> Seq Scan on ck_o_f4zrikc (cost=0.00..0.00 rows=1 width=56)
Filter: ((reg_time > '2015-11-29 00:00:00'::timestamp without time zone) AND (reg_time < '2015-11-29 09:00:00'::timestamp without time zone) AND (zagzfu_npoz = 1) AND (zagzfu_tipz = 71))
-> Index Scan using ck_o_f4zrikc_reg_time_idx20151129 on ck_o_f4zrikc20151129 (cost=0.43..42251.08 rows=628466 width=56)
Index Cond: ((reg_time > '2015-11-29 00:00:00'::timestamp without time zone) AND (reg_time < '2015-11-29 09:00:00'::timestamp without time zone))
Filter: ((zagzfu_npoz = 1) AND (zagzfu_tipz = 71))

Для SERVER
Result (cost=1.20..52158.60 rows=626550 width=56)
InitPlan 1 (returns $0)
-> Seq Scan on dic_colors dic (cost=0.00..1.20 rows=1 width=8)
Filter: (colors_id = 2)
-> Append (cost=0.00..42759.15 rows=626550 width=56)
-> Seq Scan on ck_o_f4zrikc (cost=0.00..0.00 rows=1 width=56)
Filter: ((reg_time > '2015-11-29 00:00:00'::timestamp without time zone) AND (reg_time < '2015-11-29 09:00:00'::timestamp without time zone) AND (zagzfu_npoz = 1) AND (zagzfu_tipz = 71))
-> Index Scan using ck_o_f4zrikc_reg_time_idx20151129 on ck_o_f4zrikc20151129 (cost=0.43..42759.15 rows=626549 width=56)
Index Cond: ((reg_time > '2015-11-29 00:00:00'::timestamp without time zone) AND (reg_time < '2015-11-29 09:00:00'::timestamp without time zone))
Filter: ((zagzfu_npoz = 1) AND (zagzfu_tipz = 71))

Не ужели ни кто не подскажет как разогнать производительность на сервере?

Вывод EXPLAIN (analyze, buffers)
DESKTOP

Result (cost=1.20..51679.28 rows=628467 width=56) (actual time=0.036..794.360 rows=622476 loops=1)
Buffers: shared hit=21157
InitPlan 1 (returns $0)
-> Seq Scan on dic_colors dic (cost=0.00..1.20 rows=1 width=8) (actual time=0.003..0.005 rows=1 loops=1)
Filter: (colors_id = 2)
Rows Removed by Filter: 15
Buffers: shared hit=1
-> Append (cost=0.00..42251.08 rows=628467 width=56) (actual time=0.025..434.213 rows=622476 loops=1)
Buffers: shared hit=21156
-> Seq Scan on ck_o_f4zrikc (cost=0.00..0.00 rows=1 width=56) (actual time=0.000..0.000 rows=0 loops=1)
Filter: ((reg_time > '2015-11-29 00:00:00'::timestamp without time zone) AND (reg_time < '2015-11-29 09:00:00'::timestamp without time zone) AND (zagzfu_npoz = 1) AND (zagzfu_tipz = 71))
-> Index Scan using ck_o_f4zrikc_reg_time_idx20151129 on ck_o_f4zrikc20151129 (cost=0.43..42251.08 rows=628466 width=56) (actual time=0.024..381.214 rows=622476 loops=1)
Index Cond: ((reg_time > '2015-11-29 00:00:00'::timestamp without time zone) AND (reg_time < '2015-11-29 09:00:00'::timestamp without time zone))
Filter: ((zagzfu_npoz = 1) AND (zagzfu_tipz = 71))
Buffers: shared hit=21156
Total runtime: 823.191 ms


SERVER

Result (cost=1.20..52158.60 rows=626550 width=56) (actual time=0.029..630.430 rows=622476 loops=1)
Buffers: shared hit=21784
InitPlan 1 (returns $0)
-> Seq Scan on dic_colors dic (cost=0.00..1.20 rows=1 width=8) (actual time=0.003..0.004 rows=1 loops=1)
Filter: (colors_id = 2)
Rows Removed by Filter: 15
Buffers: shared hit=1
-> Append (cost=0.00..42759.15 rows=626550 width=56) (actual time=0.019..338.309 rows=622476 loops=1)
Buffers: shared hit=21783
-> Seq Scan on ck_o_f4zrikc (cost=0.00..0.00 rows=1 width=56) (actual time=0.001..0.001 rows=0 loops=1)
Filter: ((reg_time > '2015-11-29 00:00:00'::timestamp without time zone) AND (reg_time < '2015-11-29 09:00:00'::timestamp without time zone) AND (zagzfu_npoz = 1) AND (zagzfu_tipz = 71))
-> Index Scan using ck_o_f4zrikc_reg_time_idx20151129 on ck_o_f4zrikc20151129 (cost=0.43..42759.15 rows=626549 width=56) (actual time=0.017..289.333 rows=622476 loops=1)
Index Cond: ((reg_time > '2015-11-29 00:00:00'::timestamp without time zone) AND (reg_time < '2015-11-29 09:00:00'::timestamp without time zone))
Filter: ((zagzfu_npoz = 1) AND (zagzfu_tipz = 71))
Buffers: shared hit=21783
Total runtime: 654.531 ms

Получается, что цена отличается на порядок, а производительность на копейку.
Задача для сервера такая: много оборудования заносит данные в базу (т.е. INSERT) и только одно рабочее место (максимум два) будет отображать информацию из базы (тяжелые Select'ы). Поэтому нам очень важно что бы тот поток который будет на select работал быстро.