Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
не могу получить план выполнения запроса
|
|||
|---|---|---|---|
|
#18+
Доброго времени суток. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. запрос: Код: plsql 1. план Код: plsql 1. 2. 3. увеличиваем параметр в 10 раз: Код: plsql 1. дождаться не могу (больше 15 мин) Попробовал Код: sql 1. 2. не помогло. Кто виноват? И что делать? Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2016, 18:42 |
|
||
|
не могу получить план выполнения запроса
|
|||
|---|---|---|---|
|
#18+
Gold_, В логах что-то есть, особенно на тему statistics collector? И приведите не-умолчательные настройки базы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2016, 19:24 |
|
||
|
не могу получить план выполнения запроса
|
|||
|---|---|---|---|
|
#18+
Gold_, Странно очень. 1) Приведите explain (analyze, costs, buffers, timing) для: select * from metasearch.reports_tripadvisor_auction_overview_daily2 WHERE id > 85637180 ORDER BY id ASC LIMIT 100 2)Недавно из таблицы много не удаляли (или не вставляли)? 3)autovacuum точно включен? 4)что дает \x select * from pg_stats where tablename='reports_tripadvisor_auction_overview_daily2' and attname='id'; 5)что дает \x select * from pg_stat_user_tables where relname= 'reports_tripadvisor_auction_overview_daily2' -- Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2016, 05:54 |
|
||
|
не могу получить план выполнения запроса
|
|||
|---|---|---|---|
|
#18+
Gold_, можно еще проверить предположение Максима, сделав Код: sql 1. и затем выполнить тот explain. если быстро отработает - значит скорей всего много мусора неподчищенного в таблице/индексе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2016, 08:33 |
|
||
|
не могу получить план выполнения запроса
|
|||
|---|---|---|---|
|
#18+
Alexius, хотя вру, невнимательно прочитал. врядли мой совет тут поможет раз всего одна таблица в запросе и min/max из индекса для построения плана все равно наверное будет читаться. не нашел правда в исходниках где именно это делается. можно попробовать измерить скорость выполнения запроса Код: sql 1. если он быстро отрабатывает то дело в чем-то другом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2016, 09:35 |
|
||
|
не могу получить план выполнения запроса
|
|||
|---|---|---|---|
|
#18+
AlexiusAlexius, хотя вру, невнимательно прочитал. врядли мой совет тут поможет раз всего одна таблица в запросе и min/max из индекса для построения плана все равно наверное будет читаться. не нашел правда в исходниках где именно это делается. можно попробовать измерить скорость выполнения запроса Код: sql 1. если он быстро отрабатывает то дело в чем-то другом. Вообще вероятность что min/max будут тормозить очень высокая. Я бы рекомендовал бы после всего что я написал сделать vacuum verbose analyze на эту таблицу и посмотреть что он умного написал. -- Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2016, 10:33 |
|
||
|
не могу получить план выполнения запроса
|
|||
|---|---|---|---|
|
#18+
vyegorov, Maxim Boguk,Alexius, спасибо! Начну пользоваться советами с конца: min - работает max - не дождался. Табличка InsertOnly - но не давно несколько COPY упало. Очень вероятно, что autovacuum до нее еще не добрался. Буду делать vacuum verbose analyze metasearch.reports_tripadvisor_auction_overview_daily2 после set enable_mergejoin = off; дождаться плана не смог. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. select * from pg_stats where tablename='reports_tripadvisor_auction_overview_daily2' and attname='id'; Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. select * from pg_stat_user_tables where relname= 'reports_tripadvisor_auction_overview_daily2' Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2016, 13:29 |
|
||
|
не могу получить план выполнения запроса
|
|||
|---|---|---|---|
|
#18+
Gold_vyegorov, Maxim Boguk,Alexius, спасибо! Начну пользоваться советами с конца: min - работает max - не дождался. Табличка InsertOnly - но не давно несколько COPY упало. Очень вероятно, что autovacuum до нее еще не добрался. Буду делать vacuum verbose analyze metasearch.reports_tripadvisor_auction_overview_daily2 В общем после больших COPY в таблицу рекомендуется руками vacuum делать иначе на медленных (а у вас 100% тормозные диски) дисках будут проблемы с max (и поиском верхней границы данных в таблице). Аналогично после большого delete - надо делать тоже vacuum сразу иначе будут проблемы с поиском нижней границы в таблице. -- Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2016, 13:46 |
|
||
|
не могу получить план выполнения запроса
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk, Спасибо! Но можно подробней, почему не получается даже план получить? Про "тормозные диски" как Вы это поняли? ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2016, 14:20 |
|
||
|
не могу получить план выполнения запроса
|
|||
|---|---|---|---|
|
#18+
Gold_, не очень похоже на insert only таблицу, судя по Код: sql 1. какие-то строки удалились. может быть делался copy и во время выполнения его прервали? попробуйте в логах базы ошибки поискать. explain тормозит из-за того, что планировщик хочет получить хорошую оценку числа строк и видимо в случае, когда указанный id за верхней границей histogram_bounds пытается взять максимальное значение для id из индекса (т.е. выполнить тот запрос select max(id)). а он торомозит, потому что должен просканировать все строки с конца индекса, пока не найдет неудаленную. т.е. предполагается что удалялись записи с самыми большими id. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2016, 15:09 |
|
||
|
не могу получить план выполнения запроса
|
|||
|---|---|---|---|
|
#18+
Alexius, спасибо. да вы правы, я писал выше: "Табличка InsertOnly - но недавно несколько COPY упало" Про select max(id), есть сомнения. Это точно? В гистограммах есть значения отличающие всего на 60 тыс., порядок же правильный. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2016, 15:24 |
|
||
|
не могу получить план выполнения запроса
|
|||
|---|---|---|---|
|
#18+
Gold_, Простите, а вы explain не можете дождаться или explain analyze? Ибо в первом сообщении просто explain, а потом уже explain analyze. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2016, 16:14 |
|
||
|
не могу получить план выполнения запроса
|
|||
|---|---|---|---|
|
#18+
Author the new one, Делаю explain. explain analyze попросил Maxim Boguk ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2016, 16:21 |
|
||
|
не могу получить план выполнения запроса
|
|||
|---|---|---|---|
|
#18+
Author the new oneGold_, Простите, а вы explain не можете дождаться или explain analyze? Ибо в первом сообщении просто explain, а потом уже explain analyze. Когда PG (планировщик) видит условие за пределами гистограммы статистики он на всякий случай пытается посмотреть реальный max/min значения по индексу. А тут хрен знает сколько строк добавлено без данных о видимости и начинается пляска с перебором головы таблицы по индексу. Это вариант как получить тормозное планирование не сделав analyze после batch load/batch delete. -- Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2016, 19:11 |
|
||
|
не могу получить план выполнения запроса
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk, Какая неприятная фича, тем более analyze я делал. я про диски как Вам поняли? ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2016, 20:04 |
|
||
|
не могу получить план выполнения запроса
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk, Спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2016, 10:45 |
|
||
|
не могу получить план выполнения запроса
|
|||
|---|---|---|---|
|
#18+
После многочасового VACUUM ANALYZE - заработало. Осадок остался. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2016, 14:41 |
|
||
|
не могу получить план выполнения запроса
|
|||
|---|---|---|---|
|
#18+
Gold_После многочасового VACUUM ANALYZE - заработало. Осадок остался. это ахиллесова пята пж что--то тут они придумывают, но крайне медленно я как--то налетел на такое использование табличек 1С--ом: они впендюривали в транзакции и многократно пересчитывали 100500 записей (в большом УПП расчет себестоимостей, итеративный) -- и всё это не влезало в статистику, поскольку унутри не аналайзили. планы были ужас--ужас, евпочя. (тройной вложенный нестед--луп по этим вот 100500, на полсуток эдак на иттерацию ) пришлось срочно переписывать на юзание времянок с использованием каких то костылей от 1С , которые транслировались 1С--м в нечто с неявным вызовам АНАЛАЙЗ--а этих времянок. с вывалом в стационар только готового итога. обплевался ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2016, 15:43 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=39301426&tid=1997016]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
162ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
| others: | 275ms |
| total: | 535ms |

| 0 / 0 |
