ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Быстрый запрос в explain analyze но медленный по факту
25 сообщений из 65, страница 2 из 3
  2  все
Быстрый запрос в explain analyze но медленный по факту
    #38921848
йоксель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
йоксель
Гость
VerusK,
"остальное время" может работать планировщик, если запросы редкие, партиций много, и всё для планирования ему приходится поднимать в кеш по новой с диска. у меня например были случаи стабильного планирования по ~15 сек. (в холодном состоянии)

думаю, надо поискать у вас триггера, чеки, FK-и и прочие триггерные (по факту) ограничения, нет ли там чего-то неподобающего.
...
Рейтинг: 0 / 0
31.03.2015, 08:29
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38921851
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
йоксель,

запросы совсем не редкие, один из самых частых запросов, на самом деле. FK а базе нет, ну и триггер срабатывает только на insert(кстати замерял только вставку - отрабатывает моментально), а выполняется долго update.
...
Рейтинг: 0 / 0
31.03.2015, 08:34
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38921859
йоксель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
йоксель
Гость
VerusK,

какие ограничения висят на таблице ? [цах]
какие из них -- пользуются планировщиком для отброса партиций при планировании ?

и вообще, все, что можете -- про таблицу расскажите.
...
Рейтинг: 0 / 0
31.03.2015, 08:59
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38921890
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
VerusK,

Да, похоже на планировщик — это известная фишка Постгреса при партиционировании.

Есть возможность использовать подготовленные запросы ?
При инициализации сессии подготовьте запрос и потом его только исполняйте.
...
Рейтинг: 0 / 0
31.03.2015, 09:22
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38921908
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
vyegorovVerusK,

Да, похоже на планировщик — это известная фишка Постгреса при партиционировании.

Есть возможность использовать подготовленные запросы ?
При инициализации сессии подготовьте запрос и потом его только исполняйте.

При использовании autoexplain (да и обычного explain analyze) - время планирование в actual time НЕ ИДЕТ (его вообще до 9.4 версии нигде не видно).
Тем более что планирование всегда занимает более менее одно и тоже время а тут то тормозит то нет.
Ну и надо учитывать что по словам автора топика у него вся база в памяти и поднимать с диска вроде бы ничего не надо.
Всетаки мне кажется что блокировки.


--Maxim Boguk
www.postgresql-consulting.ru
...
Рейтинг: 0 / 0
31.03.2015, 09:34
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38921914
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
VerusK

а сколько у вас на базе shared buffers стоит?
и как настроены checkpoints?

И просто для очистки совести посмотрите iostat -x -m -d 10 пару-тройку минут на предмет загрузки дисковой подсистемы.
И что у вас за дисковая подсистема?

--Maxim Boguk
www.postgresql-consulting.ru
...
Рейтинг: 0 / 0
31.03.2015, 09:39
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38921920
PgSQLAnonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PgSQLAnonymous
Гость
vyegorovVerusK,
Да, похоже на планировщик — это известная фишка Постгреса при партиционировании.


Ага, вот, например: http://www.postgresql.org/message-id/2371.1234539121@sss.pgh.pa.us]http://www.postgresql.org/message-id/2371.1234539121@sss.pgh.pa.us

vyegorovЕсть возможность использовать подготовленные запросы ?
При инициализации сессии подготовьте запрос и потом его только исполняйте.
Вот это хороший совет, IMHO, стоит попробовать.
...
Рейтинг: 0 / 0
31.03.2015, 09:42
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38921922
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
VerusK и остальные...

Снимаю свои возражения про планировщик, был невнимателен.
Это явно оно судя по:
"Planning time: 47.748 ms"

Теперь вопрос к автору топика покажите вывод \d+ stats.
Что-то у меня большие сомнения на счет 100 дочерних таблиц... такое время планирования скорее будет на 10000 дочерних таблиц.

PS: prepared запросы тут только хуже сделают... так как база будет во всех дочерних таблицах пытаться update строки а не в одной.

--Maxim Boguk
www.postgresql-consulting.ru
...
Рейтинг: 0 / 0
31.03.2015, 09:43
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38921928
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
PgSQLAnonymousvyegorovЕсть возможность использовать подготовленные запросы ?
При инициализации сессии подготовьте запрос и потом его только исполняйте.
Вот это хороший совет, IMHO, стоит попробовать.

Во избежание запутывания уважаемой аудитории и распостранения городских легенд позволю внести себе ясность в вопрос:

1)И так... prepared запрос планируется на этапе когда параметры запроса еще не известны.
2)В случае партиционирования это приводит к тому что план ВСЕГДА будет включать в себя обработку всех партиций,
так как построить универсальный план по другому - невозможно.
3)Это приводит к тому что в данной конкретной задаче будет произведена попытка поиска строк ВО ВСЕХ наличных партициях.
Что приведет еще более печальным результатам чем у автора топика наблюдаются.

Все вышеприведенное относится и к хранимкам.
По факту при использовании партиционирования приходится делать следующие вещи:
1)в prepared запросах надо ЯВНО (не параметрами) указывать условия по которым партиционируем.
2)в хранимках при работе с партиционированной таблицей использовать execute для перепланирования при каждом вызове.

--Maxim Boguk
www.postgresql-consulting.ru
...
Рейтинг: 0 / 0
31.03.2015, 09:49
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38921932
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan Durak
Участник
vacuum full всех системных таблиц попробуй
...
Рейтинг: 0 / 0
31.03.2015, 09:50
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38921969
PgSQLAnonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PgSQLAnonymous
Гость
Maxim BogukPgSQLAnonymousпропущено...

Вот это хороший совет, IMHO, стоит попробовать.

Во избежание запутывания уважаемой аудитории и распостранения городских легенд позволю внести себе ясность в вопрос:

1)И так... prepared запрос планируется на этапе когда параметры запроса еще не известны.
2)В случае партиционирования это приводит к тому что план ВСЕГДА будет включать в себя обработку всех партиций,
так как построить универсальный план по другому - невозможно.
3)Это приводит к тому что в данной конкретной задаче будет произведена попытка поиска строк ВО ВСЕХ наличных партициях.
Что приведет еще более печальным результатам чем у автора топика наблюдаются.

Да, не подумал. :(
Maxim Boguk прав, не делайте этого --- станет только хуже. ;(
Сколько у Вас партиций, в самом деле?
...
Рейтинг: 0 / 0
31.03.2015, 10:11
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38921997
йоксель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
йоксель
Гость
Maxim BogukVerusK и остальные...
<>
Что-то у меня большие сомнения на счет 100 дочерних таблиц... такое время планирования скорее будет на 10000 дочерних таблиц.
<>если много сложных индексов -- и все примерно про одно и то же, и примерно вдоль плана -- то очень даже бывает.

1. можно попробовать генерить sql динамически, с генерацией полного имени партиции -- должно спасти
2. попробовать (FK на бд по утверждению автора нет) заменить апдейт на delete + insert. (insert, по тому же утверждению, не тормозит).


3. у автора двухкомпонентное партицирование, кажется (по 2-м параметрам) -- можно попробовать перестроить иерархию -- от корня унаследовать пустышки по одному ключу, а от них -- по обоим, на обоих уровнях inherit констрайнт по первому ключу партицирования -- число переборов планером может сократится (хотя не верю - в случае наличия стопящего констрайнта типа {CHECK (FALSE) NO INHERIT} на головной именно в плане update оно зачем то аппендит такую "головную")
...
Рейтинг: 0 / 0
31.03.2015, 10:28
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38922021
йоксель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
йоксель
Гость
Maxim Boguk
2)В случае партиционирования это приводит к тому что план ВСЕГДА будет включать в себя обработку всех партиций,
так как построить универсальный план по другому - невозможно.
это зависит от того, что такое "универсальный план в СУБД". кажется оракел умеет пользоваться значением бинд переменной для конкретизации плана "в момент исполнения". могу врать.
...
Рейтинг: 0 / 0
31.03.2015, 10:40
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38922022
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
конфиг PG:

shared_buffers = 32GB
# - Checkpoints -
checkpoint_segments = 64
checkpoint_completion_target = 0.9

\d+ stats - https://gist.github.com/anonymous/77e4c1000ae39f1fffb1 таблиц даже меньше 100 :)
iostat - https://gist.github.com/anonymous/50d9041f145fe2cf12a4

йоксель,
1. Первое, что пришло в голову - не помогает :(
2. Попробую сейчас поиграться
3. Все верно, партицирование идет по 2м параметрам, по ts_spawn и по user_id - планировалось так
чтобы у пользователей стата не тормозила(на самом деле это помогло, но зато столкнулся с проблемой записи этой самой статы)
...
Рейтинг: 0 / 0
31.03.2015, 10:40
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38922042
йоксель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
йоксель
Гость
VerusK
1. Первое, что пришло в голову - не помогает :(
тогда проблема не в планировании.

тосты к партициям толстые ли ? индексы на них не протухшие ли?
я бы туда таки посмотрел, кто из них уникъю, и т.п. -- индексов то у вас просто немеряно. Если есть сильно протухшие уникъю индексы -- они будут тормозить проверкой. все время апаемая табличка нуждается в регулярных реиндексах, пичалька.
...
Рейтинг: 0 / 0
31.03.2015, 10:50
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38922050
йоксель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
йоксель
Гость
PS
ddl ЧЕК-ов мы так и не увидели.
...
Рейтинг: 0 / 0
31.03.2015, 10:54
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38922076
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
Вот код триггера, тут как раз создание дочерних таблиц - https://gist.github.com/anonymous/79d37e631892b4c2048f
...
Рейтинг: 0 / 0
31.03.2015, 11:07
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38922107
йоксель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
йоксель
Гость
VerusKВот код триггера, тут как раз создание дочерних таблиц - https://gist.github.com/anonymous/79d37e631892b4c2048f страшноватый. у вас д.б. гарантированно один писатель в stats, без конкурентов . например джоб с контролем уникальности себя в моменте. иначе -- будете все в белом.


есть надежда, что у вас сильно протухшие ваши пк (было слишком много апдейтов). Но как их неконкурентно поджать -- м.б. Максимовой утилиткой ?
...
Рейтинг: 0 / 0
31.03.2015, 11:25
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38922135
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
йоксель,

я провел эксперимент, сделал полный дамп базы и развернул его на версиях 9.2 и 9.3 - результат точно такой же, апдейт медленный. При разворачивании дампа он ведь строит индексы заново, верно?
...
Рейтинг: 0 / 0
31.03.2015, 11:38
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38922163
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
Maxim Boguk1)И так... prepared запрос планируется на этапе когда параметры запроса еще не известны.
2)В случае партиционирования это приводит к тому что план ВСЕГДА будет включать в себя обработку всех партиций,
так как построить универсальный план по другому - невозможно.

Начиная с версии 9.2 PostgreSQL поддерживает параметризованные подготовленные запросы (вторая звездочка).

Другое дело, что были жалобы (я не смогу найти быстро), что первые 4 исполнения проходят быстро, а потом планировщик переклинивает и он выбирает не оптимальные планы. Вроде эта тема была закрыта (патчами).

В связи с этим 2 вопроса:
какие конкретно версии (интересуют все 3 цифры) вы тестировали? в смысле — все ли апдейты стоят?

каким будет поведение на 9.1?
...
Рейтинг: 0 / 0
31.03.2015, 11:53
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38922191
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
vyegorov,

тестировал конкретно 9.2.4, 9.3, 9.4, 9.4.1
...
Рейтинг: 0 / 0
31.03.2015, 12:04
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38922196
йоксель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
йоксель
Гость
VerusK,
верно

но я не понимаю, как ваще
автор1. Первое, что пришло в голову - не помогает :(
соотносится с вашим же

авторОтвет на второй пост:
Если выполнять просто на таблице:
Код: sql
1.
2.
3.
<>
"Planning time: 0.675 ms"
"Execution time: 0.166 ms"




-- в первом случае есть какое-то отягощение ?
...
Рейтинг: 0 / 0
31.03.2015, 12:07
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38922222
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
йоксель,

действительно, что-то я сам запутался в экспериментах. Если указать конкретную партицию, то работает очень быстро, наверное, как и должно. 1000 строк проапдейтилась за 10сек на локале
...
Рейтинг: 0 / 0
31.03.2015, 12:20
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38922353
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vyegorov
Участник
VerusK,

А покажите вывод:
Код: sql
1.
SELECT name,setting FROM pg_settings WHERE source NOT IN ('default','override');



Код: sql
1.
SELECT * FROM pg_stat_user_tables WHERE relname ~ '^stats';



Код: sql
1.
SELECT * FROM pg_stat_bgwriter;
...
Рейтинг: 0 / 0
31.03.2015, 13:24
| Ответить | Цитировать | Написать  
Быстрый запрос в explain analyze но медленный по факту
    #38922390
VerusK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
VerusK
Гость
vyegorov,

все запросы - https://gist.github.com/anonymous/90e84a06ab8bbe60f37e
...
Рейтинг: 0 / 0
31.03.2015, 13:39
| Ответить | Цитировать | Написать  
25 сообщений из 65, страница 2 из 3
  2  все
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Быстрый запрос в explain analyze но медленный по факту
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=53&msg=38921997&tid=1998077]:
 0ms
get settings:
 7ms
get forum list:
 14ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 196ms
get topic data:
 7ms
get forum data:
 2ms
get page messages:
 39ms
get tp. blocked users:
 1ms
others: 235ms
total:  507ms
созд. / загр.: 507ms
x
x
Закрыть


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