Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Проблема с оптимизатором
|
|||
|---|---|---|---|
|
#18+
Имеются две одинаковые базы на одинаковых компах. PostgreSQL 7.4.6 На обеих базах сделан vacuum full analyze; Делаются одинаковые запросы - на первом компе запрос отрабатывает почти моментально, на втором полторы минуты :( На первом в таблице более 1млн записей, на втором около 800тыс. Вот результат explain: explain select sum(t_checkcont.amount) from t_check inner join t_checkcont on t_check.id_kassa = t_checkcont.id_kassa and t_check.check_number = t_checkcont.check_number where article='260-7170' and dtime_open > date_to_int('2004-05-11') AND dtime_open < date_to_int('2005-05-13'); Первый комп (быстро) Aggregate (cost=5756.56..5756.56 rows=1 width=10) -> Nested Loop (cost=0.00..5756.53 rows=12 width=10) -> Index Scan using tmp_i3 on t_checkcont (cost=0.00..2320.12 rows=586 width=16) Index Cond: ((article)::text = '71546'::text) -> Index Scan using t_check_pkey on t_check (cost=0.00..5.85 rows=1 width=6) Index Cond: ((t_check.id_kassa = "outer".id_kassa) AND (t_check.check_number = "outer".check_number)) Filter: ((dtime_open > 1115845200) AND (dtime_open < 1115931600)) Второй комп (медленно) Aggregate (cost=2575.28..2575.28 rows=1 width=10) -> Merge Join (cost=2560.80..2575.26 rows=6 width=10) Merge Cond: (("outer".check_number = "inner".check_number) AND ("outer".id_kassa = "inner".id_kassa)) -> Sort (cost=180.49..183.80 rows=1323 width=6) Sort Key: t_check.check_number, t_check.id_kassa -> Index Scan using tmp_i2 on t_check (cost=0.00..111.89 rows=1323 width=6) Index Cond: ((dtime_open > 1115845200) AND (dtime_open < 1115931600)) -> Sort (cost=2380.32..2381.81 rows=599 width=16) Sort Key: t_checkcont.check_number, t_checkcont.id_kassa -> Index Scan using tmp_i3 on t_checkcont (cost=0.00..2352.68 rows=599 width=16) Index Cond: ((article)::text = '71546'::text) Куда копать? Что дальше делать уже придумать не могу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2005, 20:48 |
|
||
|
Проблема с оптимизатором
|
|||
|---|---|---|---|
|
#18+
То есть на первой базе оптимизатор полагает что поиск в t_checkcont по article дешевле чем в t_check по dtime_open, а на второй видимо наоборот. Неплохо бы EXPLAIN ANALYZE увидеть, чтобы сказать насколько он ошибается. Причем во втором случае после нахождения небольшого [1323x6] числа строк, он не пытается использовать индекс t_checkcont (id_kassa, check_number) [полагаю что он есть], а выполняет затратный merge join. Может имеет смысл расширить статистику по dtime_open (alter table ... alter column ... set statistics ...)? Или наоборот, если запросов по dtime_open немного - вообще убить индекс по нему? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.05.2005, 04:00 |
|
||
|
|

start [/forum/topic.php?desktop=1&fid=53&tid=2007263]: |
0ms |
get settings: |
8ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
131ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
43ms |
get tp. blocked users: |
1ms |
| others: | 235ms |
| total: | 451ms |

| 0 / 0 |
