Postgres 9,3 медленно агрегатный

После больше настройка производительности вопрос:Postgres 9,3 медленно агрегатный

Запрос

select 
    ipc_class_symbol,count (tls201_appln.appln_id) 
from 
    tls201_appln, 
    tls209_appln_ipc 
where 
    tls201_appln.appln_id=tls209_appln_ipc.appln_id 
group by 
    tls209_appln_ipc.ipc_class_symbol

выполнен с планом

"HashAggregate (cost=9767241.49..9767481.92 rows=24043 width=16) (actual time=422312.135..422355.589 rows=72506 loops=1)" 
" Buffers: shared hit=992580" 
" -> Merge Join (cost=132.89..8764451.97 rows=200557904 width=16) (actual time=0.068..234936.829 rows=200557856 loops=1)" 
"  Merge Cond: (tls201_appln.appln_id = tls209_appln_ipc.appln_id)" 
"  Buffers: shared hit=992580" 
"  -> Index Only Scan using appln_id_idx on tls201_appln (cost=0.57..1673775.53 rows=81711664 width=4) (actual time=0.033..26993.348 rows=72642821 loops=1)" 
"    Heap Fetches: 0" 
"    Buffers: shared hit=198493" 
"  -> Index Only Scan using tls209_appln_ipc_keyidx on tls209_appln_ipc (cost=0.57..4604685.13 rows=200557904 width=16) (actual time=0.023..79085.426 rows=200557856 loops=1)" 
"    Heap Fetches: 0" 
"    Buffers: shared hit=794087" 
"Total runtime: 422366.717 ms"

и продолжительностью

Total query runtime: 358032 ms. 
72506 rows retrieved.

С моим понимания и повторного Здесь я предполагаю, что план несколько оптимален.

Машина 64GB, 8 ядро, выделенный сервер win64bit. индексные таблицы находятся на SSD, таблица по прядению.

postgresql.conf настроен на значения, которые я нашел здесь (стоимость страницы, mem и т. Д.).

Проблема в том, что тот же запрос возвращается через ~ 18 секунд на аналогичной машине с СУБД SQL Server.

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

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

Так что любые подсказки/комментарии/предложения о том, как сократить время выполнения, будут оценены наиболее высоко.

источник

2015-11-11 Felix

Пожалуйста, добавьте вывод 'объясните анализ', чтобы мы могли видеть _where_ время потеряно. К сожалению, большие скопления не являются самой сильной частью Postgres. Однако у меня была аналогичная проблема и протестирована предстоящая версия 9.5, которая имеет некоторые существенные улучшения в этой области. Мой тестовый запрос снизился с 40 секунд до 15 секунд (что примерно в то же время, когда этот запрос использовался для Oracle). 9.4 может быть уже быстрее, чем 9.3 –

Извините, отредактировано. Хорошо. Тогда я могу подождать 9,5. – Felix

Вы уже можете попробовать 9.5 бета-версию, если хотите: http://www.enterprisedb.com/products-services-training/pgdownload –

Индекс tls209_appln_ipc.ipc_class_symbol, и вы должны получить некоторую скорость из него.

источник

2015-11-13 22:35:15 KBall

это: CREATE INDEX ipc_sym_idx ПО tls209_appln_ipc ИСПОЛЬЗОВАНИЕ ВТКЕЕ (. Ipc_class_symbol COLLATE pg_catalog "POSIX" varchar_pattern_ops) TABLESPACE patstat_index; – Felix

Postgres 9,3 медленно агрегатный

ответ

Смежные вопросы