ReSQL.ru
     
powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / необьяснимая ситуация!!!
22 сообщений из 22, страница 1 из 1
необьяснимая ситуация!!!
    #32674692
Хилковский Андрей
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хилковский Андрей
Гость
Кто встречался, и может сообча поможете...над проблемой:
Льются данные в PG таким образом:
1. Порционно, из фокса сначала обсчитав-формируя строку вставки, и далее
сформированную строку исполняем все это используется через ODBC. Данные-
это траффик. Идут порционно раз в 3 минуты. И соответственно обрабатываются и выкладываются сразу же в PG. Порция около 4000 записей.
т.е. обработали запись - втавили и т.д.
2. Потоком за месяц. Т.Е. подсчитанный по тем же алгоритмам что и в первом случае траффик только за месяц, выкладывается целиком в таблицу.
Всего и в первом и втором случае количество записей около 10-15 миллионов.
Проблема такая! Если это второй случай заливки, то все запросы к этой таблице выполняются с хорошей скоростью, план исполнения показывает
нормальные стоимости, использование индексов, фильтров и т.д.
Если случай первый, то в какой-то пока необьяснимый и не пойманный момент,
происходит следущее, сначала все запросы к таблице идут совершенно нормально, и план исполнения, не уровне, потом что-то случается???, и все наперекосяк, запросы уходят в бесконечность, планн исполнения ни о каких
индексах и понятия не имеет, стоимости возрастают на порядки!!! т.е. количество страниц в нормальном сосотоянии около 10-20 тыс, а в ненормальном 800000-1000000, данные-же никуда не пропадают, они на месте
и в первом и во втором случае, но очень огромная разница!!!
Вопрос такой: что происходит, как это можно диагносцировать, какие средства
внутренние или внешние позволяют протестировать состояние проблеммной
таблицы?
система: RH AS 4.?, PG 7.45
...
Рейтинг: 0 / 0
01.09.2004, 10:14
| Ответить | Цитировать | Написать  
необьяснимая ситуация!!!
    #32675359
Хилковский Андрей
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хилковский Андрей
Гость
Кстати вот планы исполнения!!!
Это по второму плану заливки т.е. все сразу:
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)

Планы исполнения разные!!! стоимость исполнения отличается на порядки!
в чем может быть причина?
...
Рейтинг: 0 / 0
01.09.2004, 13:53
| Ответить | Цитировать | Написать  
необьяснимая ситуация!!!
    #32676865
nevermind
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nevermind
Гость
vacuum full analyze делать не пробовал?
...
Рейтинг: 0 / 0
02.09.2004, 11:08
| Ответить | Цитировать | Написать  
необьяснимая ситуация!!!
    #32678518
Хилковский Андрей
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хилковский Андрей
Гость
>vacuum full analyze делать не пробовал?
Пробовал уже все...толку 0!
...
Рейтинг: 0 / 0
03.09.2004, 07:48
| Ответить | Цитировать | Написать  
необьяснимая ситуация!!!
    #32679030
nevermind
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nevermind
Гость
Приведи примеры explain analyze, а не explain
...
Рейтинг: 0 / 0
03.09.2004, 11:58
| Ответить | Цитировать | Написать  
необьяснимая ситуация!!!
    #32679338
Хилковский Андрей
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хилковский Андрей
Гость
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
-----О, как!
...
Рейтинг: 0 / 0
03.09.2004, 13:41
| Ответить | Цитировать | Написать  
необьяснимая ситуация!!!
    #32679354
nevermind
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nevermind
Гость
а на сам запрос посмотреть можно?
...
Рейтинг: 0 / 0
03.09.2004, 13:51
| Ответить | Цитировать | Написать  
необьяснимая ситуация!!!
    #32679376
Хилковский Андрей
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хилковский Андрей
Гость
Запросто!
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)
...
Рейтинг: 0 / 0
03.09.2004, 14:01
| Ответить | Цитировать | Написать  
необьяснимая ситуация!!!
    #32679713
Sad Spirit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sad Spirit
Участник
Хилковский Андрей>vacuum full analyze делать не пробовал?
Пробовал уже все...толку 0!
по-моему ты вводишь присутствующих в заблуждение, вот этот момент
Код: plaintext
1.
2.
3.
-> 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.
...
Рейтинг: 0 / 0
03.09.2004, 16:24
| Ответить | Цитировать | Написать  
необьяснимая ситуация!!!
    #32679832
Хилковский Андрей
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хилковский Андрей
Гость
Это после 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?
как все изменилось, а?
...
Рейтинг: 0 / 0
03.09.2004, 16:55
| Ответить | Цитировать | Написать  
необьяснимая ситуация!!!
    #32680100
Sad Spirit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sad Spirit
Участник
Хилковский Андрейтабличка tel по сравнению с другой таблицей просто карлик, и по ней не проставлены индексы
ну так "проставь". индекс по num может помочь.
...
Рейтинг: 0 / 0
03.09.2004, 19:10
| Ответить | Цитировать | Написать  
необьяснимая ситуация!!!
    #32680193
Хилковский Андрей
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хилковский Андрей
Гость
Так самое то главное, что с этой же табличкой tel, другие таблички ведут себя как положено, я уже приводил EXPLAIN:
Код: plaintext
1.
2.
3.
4.
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)
Вопрос-то поста не в том как заставить работать запрос, вопрос такой: почему
при порционной заливке ФОКСОМ, таблица ведет себя одним способом, а если эти же данные залить одним потоком, то поведение и план исполнения совсем другие, это при одной и той же табличке tel ! ВОТ В ЧЕМ ВОПРОС-ТО!
Как в этом разобраться, что делается не так,может это ФОКС гадит, может еще чего, есть какие мысли, и очень спасибо за диалог nevermind и Sad Spirit если вам интересно, давайте попробуем разобраться, у меня гипотезы кончились, давайте свои я оперативно буду проверять и докладывать! Спасибо, давайте продолжим.
...
Рейтинг: 0 / 0
03.09.2004, 22:14
| Ответить | Цитировать | Написать  
необьяснимая ситуация!!!
    #32680210
Sad Spirit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sad Spirit
Участник
Хилковский АндрейВопрос-то поста не в том как заставить работать запрос, вопрос такой: почему
при порционной заливке ФОКСОМ, таблица ведет себя одним способом, а если эти же данные залить одним потоком, то поведение и план исполнения совсем другие, это при одной и той же табличке tel! ВОТ В ЧЕМ ВОПРОС-ТО!

Давай всё же определимся: тебе запрос ускорить или расследование провести?..

Как заставить сервер может выбирать верный план запроса?
1) Настройка параметров сервера (которые мы покуда не видели)
2) Построение дополнительных индексов
3) Эксперименты с SET enable_...=off;
Ясное дело, что статистика должна быть актуальной (не забывать vacuum analyze)

Понять, почему выбирается неверный план --- практически нереально. Фокс-то тут явно не при чём.

У меня подозрение, что как раз выбор верного плана у тебя --- случайность, т.к. статистика сбита и индексов нет.
...
Рейтинг: 0 / 0
04.09.2004, 00:06
| Ответить | Цитировать | Написать  
необьяснимая ситуация!!!
    #32680213
Shweik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shweik
Участник
Не совсем понятно что значит "одним потоком"?
Что меньше внесет хаоса в статистику 1 Транзакция или 4000*20*30?
IMHO все достаточно прозрачно, если помнить что статистику
постмастер обновляет далеко не всю а планировщик
от этого страдает.

13.4.5. Run ANALYZE Afterwards

It's a good idea to run ANALYZE or VACUUM ANALYZE anytime you've added or updated a lot of data, including just after initially populating a table. This ensures that the planner has up-to-date statistics about the table. With no statistics or obsolete statistics, the planner may make poor choices of query plans, leading to bad performance on queries that use your table.
И ничего не объяснимого.
...
Рейтинг: 0 / 0
04.09.2004, 00:12
| Ответить | Цитировать | Написать  
необьяснимая ситуация!!!
    #32680876
Хилковский Андрей
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хилковский Андрей
Гость
Sad SpiritДавай всё же определимся: тебе запрос ускорить или расследование провести?..

Как заставить сервер может выбирать верный план запроса?
1) Настройка параметров сервера (которые мы покуда не видели)
2) Построение дополнительных индексов
3) Эксперименты с SET enable_...=off;
Ясное дело, что статистика должна быть актуальной (не забывать vacuum analyze)

Понять, почему выбирается неверный план --- практически нереально. Фокс-то тут явно не при чём.

У меня подозрение, что как раз выбор верного плана у тебя --- случайность, т.к. статистика сбита и индексов нет.
1)По настройкам сервера, обращался к нашим системщикам, они списывались с разработчиками, в ответе сказано, что настройки оптимальные, вроде все хорошо, ведь не со всеми таблицами одинаковой емкости так работает а только, с той в которую льется или залилось с пом 1-го метода заливки.
2)Опять же по поводу доп.индексов, это исключение а не правило, т.е. все остальные талицы и выборки на нормальном уровне.
3)Ставлю SET ENABLE_SEQSCAN to OFF, так сканирование и идет по индексу,
проблема в том что сканирование по индексу идет не по нормальному, если посмотреть сканирования по нормальной таблице то:
Код: plaintext
1.
Index Scan using callsh200408_num_index on callsh200408 c (cost= 0 . 00 .. 12 . 47  rows= 405  width= 71 )
Index Cond: (c.num = "outer".num)
а по ненормальной:
Код: plaintext
Index Scan using callsh200409_num_index on callsh200409 c  (cost= 0 . 00 .. 139506 . 28  rows= 1862751  width= 75 ) (actual time= 0 . 133 .. 33582 . 077  rows= 1862751  loops= 1 )
И во втором случае это после vacuum full analyze callsh200409 и tel.
т.е. индексное сканирование идет ужасно долго и с огромными ресурсами.
а то почему не строю индекс по табличке tel, обьясню, этот запрос на самом деле в функции, и табличка tel учавствует, только в предварительной выборке данных во временную, куда всего попадает максимум 1-5 записей.
Может еще чего сделать, если и статистика обновлена насильно, а воз пока на месте...
...
Рейтинг: 0 / 0
06.09.2004, 10:15
| Ответить | Цитировать | Написать  
необьяснимая ситуация!!!
    #32680902
Хилковский Андрей
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хилковский Андрей
Гость
ShweikНе совсем понятно что значит "одним потоком"?
Это значит что берется таблица ДБФ и в фоксе и целиком ее одними
последовательными инсертами пихается в ПГ, а в первом случае, эти инсерты размазаны по всему месяцу, т.е. заливаются суточные порции...
ShweikЧто меньше внесет хаоса в статистику 1 Транзакция или 4000*20*30?
Транзакции и в первом и втором случаях заливки одинаковы-автоматические при выполнении команды ИНСЕРТ...
ShweikIMHO все достаточно прозрачно, если помнить что статистику
постмастер обновляет далеко не всю а планировщик
от этого страдает.
А как тогда обьяснить, что после обновления статистики, результат не ОБНОВЛЯЕТСЯ? т.е. сканирование по индексу показывает что поднимаются все актенты и соответственно все данные индекса?

Shweik13.4.5. Run ANALYZE Afterwards

It's a good idea to run ANALYZE or VACUUM ANALYZE anytime you've added or updated a lot of data, including just after initially populating a table. This ensures that the planner has up-to-date statistics about the table. With no statistics or obsolete statistics, the planner may make poor choices of query plans, leading to bad performance on queries that use your table.
И ничего не объяснимого.
Согласен, но когда таблички залиты вторым способом: сразу, а не размазанными по месяцу, все и работает, проблема только в завидном постоянстве, долгого и ресурсного сканирования по индексу независимо, от количества раз обновления статистики. А если дело не в этом, тогда в чем, есть предположения?
...
Рейтинг: 0 / 0
06.09.2004, 10:27
| Ответить | Цитировать | Написать  
необьяснимая ситуация!!!
    #32680975
Хилковский Андрей
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хилковский Андрей
Гость
Только что сделал vacuum verbose analyze callsh200409:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
INFO:  vacuuming "public.callsh200409"
INFO:  index "callsh200409_num_index" now contains  1878714  row versions in  9524  pages
DETAIL:   0  index pages have been deleted,  0  are currently reusable.
CPU  0 .37s/ 0 .09u sec elapsed  39 . 75  sec.
INFO:  "callsh200409": found  0  removable,  1878714  nonremovable row versions in  27629  pages
DETAIL:   0  dead row versions cannot be removed yet.
There were  0  unused item pointers.
 0  pages are entirely empty.
CPU  1 .34s/ 0 .29u sec elapsed  72 . 76  sec.
INFO:  analyzing "public.callsh200409"
INFO:  "callsh200409":  27629  pages,  12000  rows sampled,  1878772  estimated total rows
Запрос успешно завершён без результата возврата за  73765  мс.
А это сразу же: EXPLAIN ANALYZE SELECT
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
explain analyze 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)

Merge Join  (cost= 52411 . 41 .. 616227 . 20  rows= 1698339  width= 145 ) (actual time= 15009 . 207 .. 177988 . 512  rows= 1877653  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 .. 140654 . 61  rows= 1878714  width= 75 ) (actual 
!!!!Вот чудо-то ^^^        ^^^^^ поднимаются все строки
time= 0 . 123 .. 13603 . 115  rows= 1878714  loops= 1 )
  ->  Sort  (cost= 52411 . 41 .. 53521 . 79  rows= 444151  width= 70 ) (actual time= 15008 . 443 .. 29546 . 062  rows= 12120140  loops= 1 )
        Sort Key: t.num
        ->  Seq Scan on tel t  (cost= 0 . 00 .. 10748 . 51  rows= 444151  width= 70 ) (actual time= 0 . 019 .. 554 . 987  rows= 444151  loops= 1 )
Total runtime:  179364 . 794  ms"
Сканирование по индексу показывает чудные результаты, есть мысли почему?
...
Рейтинг: 0 / 0
06.09.2004, 11:00
| Ответить | Цитировать | Написать  
необьяснимая ситуация!!!
    #32681367
Sad Spirit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sad Spirit
Участник
Хилковский АндрейСогласен, но когда таблички залиты вторым способом: сразу, а не размазанными по месяцу, все и работает, проблема только в завидном постоянстве, долгого и ресурсного сканирования по индексу независимо, от количества раз обновления статистики. А если дело не в этом, тогда в чем, есть предположения?
Наиболее вероятное: может быть данные в этих двух случаях попадают в таблицу в разном физическом порядке?
...
Рейтинг: 0 / 0
06.09.2004, 13:50
| Ответить | Цитировать | Написать  
необьяснимая ситуация!!!
    #32681434
Хилковский Андрей
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хилковский Андрей
Гость
Sad Spirit Хилковский АндрейСогласен, но когда таблички залиты вторым способом: сразу, а не размазанными по месяцу, все и работает, проблема только в завидном постоянстве, долгого и ресурсного сканирования по индексу независимо, от количества раз обновления статистики. А если дело не в этом, тогда в чем, есть предположения?
Наиболее вероятное: может быть данные в этих двух случаях попадают в таблицу в разном физическом порядке?
т.е. нужно попробовать кластеризовать? но эксперимент был проведен такой, кластеризовали таблички, но не делали потом обновление статистики, считали что при кластеризазии, статистика должна обновляться, т.к. мы меняем не данные а порядок их размещения (может это была ошибка?), но результат оказался таким же...Может проверить еще раз но только с обновлением статистики?
...
Рейтинг: 0 / 0
06.09.2004, 14:15
| Ответить | Цитировать | Написать  
необьяснимая ситуация!!!
    #32681451
wbear
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
wbear
Участник
мож просто индекс поломался REINDEX делал?
...
Рейтинг: 0 / 0
06.09.2004, 14:22
| Ответить | Цитировать | Написать  
необьяснимая ситуация!!!
    #32681825
Хилковский Андрей
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хилковский Андрей
Гость
wbearмож просто индекс поломался REINDEX делал?
Делал! И не просто, а убивал и индексировал заново!
...
Рейтинг: 0 / 0
06.09.2004, 16:37
| Ответить | Цитировать | Написать  
необьяснимая ситуация!!!
    #32690640
antix
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
antix
Гость
:( такая же ситуация, но с 8 бетой постгре. с 7.4.3 все было нормально. Заливка данных из фокса. После большого количества инсертов перестает использовать индекс по таблице. После RECREATE индекса, планировщик снова его начинает юзать:((
...
Рейтинг: 0 / 0
11.09.2004, 14:04
| Ответить | Цитировать | Написать  
22 сообщений из 22, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / необьяснимая ситуация!!!
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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