powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Проблема с оптимизатором
2 сообщений из 2, страница 1 из 1
Проблема с оптимизатором
    #33060924
Hordi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Имеются две одинаковые базы на одинаковых компах. 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)


Куда копать? Что дальше делать уже придумать не могу.
...
Рейтинг: 0 / 0
Проблема с оптимизатором
    #33061129
фффф
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
То есть на первой базе оптимизатор полагает что поиск в 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 немного - вообще убить индекс по нему?
...
Рейтинг: 0 / 0
2 сообщений из 2, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Проблема с оптимизатором
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]