V
Вы пишете в своем запросе ONLY, это указание изменить только основную таблицу. Уберите ONLY
Size: a a a
2020 May 20
V
В документации написано что для применения только к основной таблице должно использоваться NO INHERIT, zipchek это название ограничения в примере
YS
Коллеги, добрый вечер. И снова я со своим уже не таким "мистическим" запросом. :)
Мои попытки посоздавать разные статистики благополучно провалились, но зато внезапно действительно помогло это расширение AQO. Результат попахивает магией, но для "мистического запроса" самое то :)
Мои попытки посоздавать разные статистики благополучно провалились, но зато внезапно действительно помогло это расширение AQO. Результат попахивает магией, но для "мистического запроса" самое то :)
Вы их всё равно до конца не довели, попытки эти (по крайней мере, тут Вы об этом не писали, так?). ;)
.P
Yaroslav Schekin
Вы их всё равно до конца не довели, попытки эти (по крайней мере, тут Вы об этом не писали, так?). ;)
не писал, но вряд ли они интересны :) чисто методом тыка, и всё равно ничего не получилось
YS
Результаты:
psql (12.1)
query (немного отличается, наверное из-за другой версии DBD::Pg):
Результат до оптимизации с помощью AQO: https://explain.depesz.com/s/CIdF
Результат после оптимизации: https://explain.depesz.com/s/b76v
Если интересны какие-нибудь тесты-запросы, готов сегодня погонять, пока база жива :)
И большое спасибо всем поучаствовавшим!
psql (12.1)
query (немного отличается, наверное из-за другой версии DBD::Pg):
SELECT DISTINCT main.* FROM Users main CROSS JOIN ACL ACL_3 JOIN Principals Principals_1 ON ( Principals_1.id = main.id ) JOIN CachedGroupMembers CachedGroupMembers_2 ON ( CachedGroupMembers_2.MemberId = Principals_1.id ) JOIN CachedGroupMembers CachedGroupMembers_4 ON ( CachedGroupMembers_4.MemberId = Principals_1.id ) WHERE ((ACL_3.ObjectType = 'RT::Queue' AND ACL_3.ObjectId = 55) OR (ACL_3.ObjectType = 'RT::System' AND ACL_3.ObjectId = 1)) AND (ACL_3.PrincipalId = CachedGroupMembers_4.GroupId) AND (ACL_3.PrincipalType = 'Group') AND (ACL_3.RightName = 'OwnTicket' OR ACL_3.RightName = 'SuperUser') AND (CachedGroupMembers_2.Disabled = '0') AND (CachedGroupMembers_2.GroupId = '4') AND (CachedGroupMembers_4.Disabled = '0') AND (Principals_1.Disabled = '0') AND (Principals_1.PrincipalType = 'User') AND (Principals_1.id != '1') ORDER BY main.Name ASC
Результат до оптимизации с помощью AQO: https://explain.depesz.com/s/CIdF
Результат после оптимизации: https://explain.depesz.com/s/b76v
Если интересны какие-нибудь тесты-запросы, готов сегодня погонять, пока база жива :)
И большое спасибо всем поучаствовавшим!
Да с точными оценками кто хочешь оптимизирует, большое дело (и планы опять без buffers). ;)
> Результат попахивает магией, но для "мистического запроса" самое то :)
У этого, мне кажется, есть и обратная сторона — AQO не бесплатен, что по времени планирования, что по хранению статистики (а уж если результат работы AQO "крив", то что делать — разберутся только его авторы, наверное ;) ).
> Результат попахивает магией, но для "мистического запроса" самое то :)
У этого, мне кажется, есть и обратная сторона — AQO не бесплатен, что по времени планирования, что по хранению статистики (а уж если результат работы AQO "крив", то что делать — разберутся только его авторы, наверное ;) ).
Р
Вы пишете в своем запросе ONLY, это указание изменить только основную таблицу. Уберите ONLY
сейчас не могу, завтра смогу.
тоже уже об этом подумал про ONLY, когда сюда кинул.
спасибо за совет, проверю завтра.
тоже уже об этом подумал про ONLY, когда сюда кинул.
спасибо за совет, проверю завтра.
YS
не писал, но вряд ли они интересны :) чисто методом тыка, и всё равно ничего не получилось
Таким методом запросы оптимизировать вряд ли удастся. ;)
Вам же там подсказывали, что нужно делать / как продолжать, кажется...
Вам же там подсказывали, что нужно делать / как продолжать, кажется...
YS
Хитрые правила тут до лампочки, мне хочется просто понять, как решить проблему того, что уникальность индекса проверяется для каждой строки, а не для результата запроса.
Ну а почему, всё-таки, не курсоры?
E
Yaroslav Schekin
Ну а почему, всё-таки, не курсоры?
А причём тут курсоры?
YS
А причём тут курсоры?
При том, что с их помощью можно делать UPDATE в любом порядке, в каком Вам захочется.
.P
Yaroslav Schekin
Да с точными оценками кто хочешь оптимизирует, большое дело (и планы опять без buffers). ;)
> Результат попахивает магией, но для "мистического запроса" самое то :)
У этого, мне кажется, есть и обратная сторона — AQO не бесплатен, что по времени планирования, что по хранению статистики (а уж если результат работы AQO "крив", то что делать — разберутся только его авторы, наверное ;) ).
> Результат попахивает магией, но для "мистического запроса" самое то :)
У этого, мне кажется, есть и обратная сторона — AQO не бесплатен, что по времени планирования, что по хранению статистики (а уж если результат работы AQO "крив", то что делать — разберутся только его авторы, наверное ;) ).
по хранению статистики - ну, там пара килобайт от силы для одного этого запроса.
Насчёт времени планирования трудно сказать, субъективно ничего не замедлилось. Включил лог для slow queries c порогом в полсекунды, за исключением этого, ещё не оптимизированного, всё пусто.
Мне больше интересно, как он в продакшене будет, стабилен ли..
Насчёт времени планирования трудно сказать, субъективно ничего не замедлилось. Включил лог для slow queries c порогом в полсекунды, за исключением этого, ещё не оптимизированного, всё пусто.
Мне больше интересно, как он в продакшене будет, стабилен ли..
.P
Yaroslav Schekin
Да с точными оценками кто хочешь оптимизирует, большое дело (и планы опять без buffers). ;)
> Результат попахивает магией, но для "мистического запроса" самое то :)
У этого, мне кажется, есть и обратная сторона — AQO не бесплатен, что по времени планирования, что по хранению статистики (а уж если результат работы AQO "крив", то что делать — разберутся только его авторы, наверное ;) ).
> Результат попахивает магией, но для "мистического запроса" самое то :)
У этого, мне кажется, есть и обратная сторона — AQO не бесплатен, что по времени планирования, что по хранению статистики (а уж если результат работы AQO "крив", то что делать — разберутся только его авторы, наверное ;) ).
без buffers - я сейчас просто следовал их readme. Могу замерить и с buffers.
E
Yaroslav Schekin
При том, что с их помощью можно делать UPDATE в любом порядке, в каком Вам захочется.
Ну можно, но мне хотелось это решить просто апдейтом. Например, заменив unique index на unique deferred constraint :)
.P
Yaroslav Schekin
Таким методом запросы оптимизировать вряд ли удастся. ;)
Вам же там подсказывали, что нужно делать / как продолжать, кажется...
Вам же там подсказывали, что нужно делать / как продолжать, кажется...
боюсь, другие методы за пределами моих квалификаций. :(
Это надо довольно плотно садиться учить-разбираться с Pg, что для меня немного непрофильно.
Возможно потом, если вдруг найдём себе настоящего DBA. И будет о чём спросить на собеседовании 😂
Это надо довольно плотно садиться учить-разбираться с Pg, что для меня немного непрофильно.
Возможно потом, если вдруг найдём себе настоящего DBA. И будет о чём спросить на собеседовании 😂
S
Всем привет. Вопрос весьма странный, но всё же) Подскажите, пожалуйста, следующую вещь. Постгрес 10, есть некий селект на тяжелую таблицу который очень долго выполняется и в это время диск на read забит на 100%. Это вызывает хреновый эффект - соседние запросы на select/update/etc начинают долго выполняться. Можно как то ограничить использование диска запросами?
YS
по хранению статистики - ну, там пара килобайт от силы для одного этого запроса.
Насчёт времени планирования трудно сказать, субъективно ничего не замедлилось. Включил лог для slow queries c порогом в полсекунды, за исключением этого, ещё не оптимизированного, всё пусто.
Мне больше интересно, как он в продакшене будет, стабилен ли..
Насчёт времени планирования трудно сказать, субъективно ничего не замедлилось. Включил лог для slow queries c порогом в полсекунды, за исключением этого, ещё не оптимизированного, всё пусто.
Мне больше интересно, как он в продакшене будет, стабилен ли..
> Насчёт времени планирования трудно сказать, субъективно ничего не замедлилось.
А объективно — замедлилось в шесть раз (40.331 / 6.612).
> по хранению статистики - ну, там пара килобайт от силы для одного этого запроса.
Понятно. Это ерунда, да.
А объективно — замедлилось в шесть раз (40.331 / 6.612).
> по хранению статистики - ну, там пара килобайт от силы для одного этого запроса.
Понятно. Это ерунда, да.
DM
Всем привет. Вопрос весьма странный, но всё же) Подскажите, пожалуйста, следующую вещь. Постгрес 10, есть некий селект на тяжелую таблицу который очень долго выполняется и в это время диск на read забит на 100%. Это вызывает хреновый эффект - соседние запросы на select/update/etc начинают долго выполняться. Можно как то ограничить использование диска запросами?
докинуть индексы под условия запроса?
S
Не, тут от обратного надо)) разработчики наговнякали где то и в итоге: индекс по полю в котором int, а в запросе используется upper и индекс не срабатывает. Запрос они переделают, но есть высокая вероятность что где то еще такие запросы есть
S
я просто с postgresql почти не работал, с mysql довольно много опыта, но там я не видел чтобы всего лишь 1 селект на таблицу-миллионик мог загрузить диск на 100%
S
пусть он там без индексов был и выполнялся 10-20 минут,но нагрузку диска на 100% это никогда не создавало