необьяснимая ситуация!!!

Хилковский Андрей
Дата: 01.09.2004 10:14:12
Кто встречался, и может сообча поможете...над проблемой:
Льются данные в PG таким образом:
1. Порционно, из фокса сначала обсчитав-формируя строку вставки, и далее
сформированную строку исполняем все это используется через ODBC. Данные-
это траффик. Идут порционно раз в 3 минуты. И соответственно обрабатываются и выкладываются сразу же в PG. Порция около 4000 записей.
т.е. обработали запись - втавили и т.д.
2. Потоком за месяц. Т.Е. подсчитанный по тем же алгоритмам что и в первом случае траффик только за месяц, выкладывается целиком в таблицу.
Всего и в первом и втором случае количество записей около 10-15 миллионов.
Проблема такая! Если это второй случай заливки, то все запросы к этой таблице выполняются с хорошей скоростью, план исполнения показывает
нормальные стоимости, использование индексов, фильтров и т.д.
Если случай первый, то в какой-то пока необьяснимый и не пойманный момент,
происходит следущее, сначала все запросы к таблице идут совершенно нормально, и план исполнения, не уровне, потом что-то случается???, и все наперекосяк, запросы уходят в бесконечность, планн исполнения ни о каких
индексах и понятия не имеет, стоимости возрастают на порядки!!! т.е. количество страниц в нормальном сосотоянии около 10-20 тыс, а в ненормальном 800000-1000000, данные-же никуда не пропадают, они на месте
и в первом и во втором случае, но очень огромная разница!!!
Вопрос такой: что происходит, как это можно диагносцировать, какие средства
внутренние или внешние позволяют протестировать состояние проблеммной
таблицы?
система: RH AS 4.?, PG 7.45
Хилковский Андрей
Дата: 01.09.2004 13:53:10
Кстати вот планы исполнения!!!
Это по второму плану заливки т.е. все сразу:
Nested Loop (cost=0.00..22616.36 rows=45012 width=141)
Join Filter: (("inner".dat >= "outer".con_d) AND (("inner".dat)::timestamp with time zone <= CASE WHEN ("outer".ret IS NULL) THEN now() ELSE ("outer".ret)::timestamp with time zone END))
-> Seq Scan on tel t (cost=0.00..20.00 rows=1000 width=70)
-> Index Scan using callsh200408_num_index on callsh200408 c (cost=0.00..12.47 rows=405 width=71)
Index Cond: (c.num = "outer".num)
---------------------------------------------------------------------------
Это по второму Плану заливки!
Merge Join (cost=69.83..879555.00 rows=50017 width=145)
Merge Cond: ("outer".num = "inner".num)
Join Filter: (("outer".dat >= "inner".con_d) AND (("outer".dat)::timestamp with time zone <= CASE WHEN ("inner".ret IS NULL) THEN now() ELSE ("inner".ret)::timestamp with time zone END))
-> Index Scan using callsh200408__num_index on callsh200408_ c (cost=0.00..838411.23 rows=11477924 width=75)
-> Sort (cost=69.83..72.33 rows=1000 width=70)
Sort Key: t.num
-> Seq Scan on tel t (cost=0.00..20.00 rows=1000 width=70)

Планы исполнения разные!!! стоимость исполнения отличается на порядки!
в чем может быть причина?
nevermind
Дата: 02.09.2004 11:08:41
vacuum full analyze делать не пробовал?
Хилковский Андрей
Дата: 03.09.2004 07:48:09
>vacuum full analyze делать не пробовал?
Пробовал уже все...толку 0!
nevermind
Дата: 03.09.2004 11:58:43
Приведи примеры explain analyze, а не explain
Хилковский Андрей
Дата: 03.09.2004 13:41:06
Explain Analize: Это с сентябрьской таблицей!, в которой записей всего-то
миллион с небольшим, Но катастрофа очевидна....
------------------------------------------------------------------------------
Merge Join (cost=69.83..47019.60 rows=3464 width=145) (actual time=34242.468..211318.139 rows=1063643 loops=1)
Merge Cond: ("outer".num = "inner".num)
Join Filter: (("outer".dat >= "inner".con_d) AND (("outer".dat)::timestamp with time zone <= CASE WHEN ("inner".ret IS NULL) THEN now() ELSE ("inner".ret)::timestamp with time zone END))
-> Index Scan using callsh200409_num_index on callsh200409 c (cost=0.00..44476.94 rows=646272 width=75) (actual time=1225.637..91684.723 rows=1063761 loops=1)
-> Sort (cost=69.83..72.33 rows=1000 width=70) (actual time=32992.907..41314.298 rows=7088657 loops=1)
Sort Key: t.num
-> Seq Scan on tel t (cost=0.00..20.00 rows=1000 width=70) (actual time=0.028..14796.111 rows=444151 loops=1)
----------------------------------------------------------------------
Total runtime: 212443.719 ms
-----О, как!
nevermind
Дата: 03.09.2004 13:51:10
а на сам запрос посмотреть можно?
Хилковский Андрей
Дата: 03.09.2004 14:01:03
Запросто!
select * from callsh200409 c inner join tel t on c.num=t.num and
c.dat between t.con_d and (case when t.ret is null then now() else t.ret end)
Sad Spirit
Дата: 03.09.2004 16:24:33
Хилковский Андрей
>vacuum full analyze делать не пробовал?
Пробовал уже все...толку 0!

по-моему ты вводишь присутствующих в заблуждение, вот этот момент
-> Sort (cost=69.83..72.33 rows=1000 width=70) (actual time=32992.907..41314.298 rows=7088657 loops=1)
Sort Key: t.num
-> Seq Scan on tel t (cost=0.00..20.00 rows=1000 width=70) (actual time=0.028..14796.111 rows=444151 loops=1)
ясно показывает, что для таблицы tel используется статистика по умолчанию, то есть по ней никогда не делался ANALYZE.
Хилковский Андрей
Дата: 03.09.2004 16:55:45
Это после vacuum full analyze tel:
Merge Join (cost=52411.41..242453.08 rows=584218 width=145) (actual time=13671.687..217900.005 rows=1167501 loops=1)
Merge Cond: ("outer".num = "inner".num)
Join Filter: (("outer".dat >= "inner".con_d) AND (("outer".dat)::timestamp with time zone <= CASE WHEN ("inner".ret IS NULL) THEN now() ELSE ("inner".ret)::timestamp with time zone END))
-> Index Scan using callsh200409_num_index on callsh200409 c (cost=0.00..44476.94 rows=646272 width=75) (actual time=9.152..111048.915 rows=1167716 loops=1)
-> Sort (cost=52411.41..53521.79 rows=444151 width=70) (actual time=13661.890..22707.233 rows=7756001 loops=1)
Sort Key: t.num"
-> Seq Scan on tel t (cost=0.00..10748.51 rows=444151 width=70) (actual time=0.006..450.707 rows=444151 loops=1)
"Total runtime: 218759.665 ms"
табличка tel по сравнению с другой таблицей просто карлик, и по ней не проставлены индексы, так что сканирование tel, это нормально, все упирается в дикую стоимость сканирования индекса второй внешней таблицы, вот где засада... И вот теперь общее впечатление после vacuum full analyze tel?
как все изменилось, а?