ВМ
это про него речь?
Size: a a a
2021 February 26
ВМ
Только повторюсь, я не прогер, переписывать его будут, мне просто надо сделать чтобы уже сейчас было быстро), за счёт серверной оптимизации
РЖ
Ага. Лучше только текстом.
ВМ
Я вот по этому ориентируюсь
РЖ
Сдаётся мне, по эдикейшн айди с какой--то стороны индекса нет. По картинке тяжело сказать.
Ещё неплохо бы структуру таблиц показать. Текстом :)
Ещё неплохо бы структуру таблиц показать. Текстом :)
ВМ
Роман Жарков
Сдаётся мне, по эдикейшн айди с какой--то стороны индекса нет. По картинке тяжело сказать.
Ещё неплохо бы структуру таблиц показать. Текстом :)
Ещё неплохо бы структуру таблиц показать. Текстом :)
там в запросе 9 джойнов)
YS
Доброго всем дня. Пытаюсь нагуглить как можно ускорить Index Scan не переписывая код, а именно настройками сервера, что-то плохо выходит. Подскажите в какую сторону копнуть?
В сторону показывания текстом (или ссылкой на paste) версии PostgreSQL, запроса, как минимум EXPLAIN (ANALYZE, BUFFERS), и, в идеале, \d каждой участвующей таблицы.
ВМ
Ну начну с простого, версия 13, на проде ещё 11, на 11 было хуже. Сейчас разберусь с остальным
YS
Ну начну с простого, версия 13, на проде ещё 11, на 11 было хуже. Сейчас разберусь с остальным
13.что? (На всякий случай).
И тогда можно показать уж "EXPLAIN (ANALYZE, BUFFERS, VERBOSE, SETTINGS) SELECT ...", чтоб потом про всякое не спрашивать. ;)
И тогда можно показать уж "EXPLAIN (ANALYZE, BUFFERS, VERBOSE, SETTINGS) SELECT ...", чтоб потом про всякое не спрашивать. ;)
ВМ
Yaroslav Schekin
13.что? (На всякий случай).
И тогда можно показать уж "EXPLAIN (ANALYZE, BUFFERS, VERBOSE, SETTINGS) SELECT ...", чтоб потом про всякое не спрашивать. ;)
И тогда можно показать уж "EXPLAIN (ANALYZE, BUFFERS, VERBOSE, SETTINGS) SELECT ...", чтоб потом про всякое не спрашивать. ;)
YS
Запрос показывали (может, пропустил)?
Но видно уже, что postgres тут практически не настраивался — вряд ли это адекватно современному "железу" и нагрузкам.
Но видно уже, что postgres тут практически не настраивался — вряд ли это адекватно современному "железу" и нагрузкам.
ВМ
work_mem=20MB
shared_buffers=2GB
huge_pages=on
synchronous_commit=off
full_page_writes=off
всё что там правилось
ВМ
Yaroslav Schekin
Запрос показывали (может, пропустил)?
Но видно уже, что postgres тут практически не настраивался — вряд ли это адекватно современному "железу" и нагрузкам.
Но видно уже, что postgres тут практически не настраивался — вряд ли это адекватно современному "железу" и нагрузкам.
ВМ
Yaroslav Schekin
Запрос показывали (может, пропустил)?
Но видно уже, что postgres тут практически не настраивался — вряд ли это адекватно современному "железу" и нагрузкам.
Но видно уже, что postgres тут практически не настраивался — вряд ли это адекватно современному "железу" и нагрузкам.
железо современное
YS
Знаете, наличие "SELECT DISTINCT" в запросе — это 95% вероятности, что кто-то не осилил написать правильный, и пытался замести непонятные ему дубликаты под ковёр. ;(
Т.е. даже смотреть дальше не хочется, честное слово — запрос почти наверняка всё равно нужно исправлять, что толку "оптимизацией" заниматься?
И да, если это взято из production — константы вместо параметров как бы намекают нам на чей-то "профессионализм". :(
Т.е. даже смотреть дальше не хочется, честное слово — запрос почти наверняка всё равно нужно исправлять, что толку "оптимизацией" заниматься?
И да, если это взято из production — константы вместо параметров как бы намекают нам на чей-то "профессионализм". :(
YS
железо современное
Ну так настраивать под него надо. См. http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server и так далее.
ВМ
Yaroslav Schekin
Знаете, наличие "SELECT DISTINCT" в запросе — это 95% вероятности, что кто-то не осилил написать правильный, и пытался замести непонятные ему дубликаты под ковёр. ;(
Т.е. даже смотреть дальше не хочется, честное слово — запрос почти наверняка всё равно нужно исправлять, что толку "оптимизацией" заниматься?
И да, если это взято из production — константы вместо параметров как бы намекают нам на чей-то "профессионализм". :(
Т.е. даже смотреть дальше не хочется, честное слово — запрос почти наверняка всё равно нужно исправлять, что толку "оптимизацией" заниматься?
И да, если это взято из production — константы вместо параметров как бы намекают нам на чей-то "профессионализм". :(
Да, его будут переписывать, я просто хотел как-то улучшить положение пока это не сделали. То есть никакими буферами и кешами я не компенсирую повторное открытие? Я не говорю про первое.
YS
Да, его будут переписывать, я просто хотел как-то улучшить положение пока это не сделали. То есть никакими буферами и кешами я не компенсирую повторное открытие? Я не говорю про первое.
Какое "улучшить"?
Т.е. Вы хотите, чтобы запрос возвращал неправильный результат быстрее?!
Это без меня, пожалуйста. ;)
Да и вообще, запрос-то написан [очень] плохо — PostgreSQL такого "не прощает".
Но настройкой стоило бы заняться в любом случае, IMHO.
Т.е. Вы хотите, чтобы запрос возвращал неправильный результат быстрее?!
Это без меня, пожалуйста. ;)
Да и вообще, запрос-то написан [очень] плохо — PostgreSQL такого "не прощает".
Но настройкой стоило бы заняться в любом случае, IMHO.
DS
Всем привет!
На питоне в библиотеке psycopg2 метод fetchone берет результаты первого запроса или последнего?
На питоне в библиотеке psycopg2 метод fetchone берет результаты первого запроса или последнего?