АК
по типу хинтов в oracle
Size: a a a
2020 June 03
s
Вы не поверите. Он сам это делает, если может и планировщик считает это имеющим смысл.
Ð
еще вопрос - какой вы ставите рандом кост на ссд?
АФ
Yaroslav Schekin
> Дробить на inlined я кстати не пробовал (не умел тогда).
Ну так а что Вы вообще измеряли, в таком случае? ;) Я, например, именно про них писал и их советовал, если что.
Те SQL functions, которые не inline-атся, могут быть даже хуже, чем plpgsql (или на других PL) — я там писал выше.
> Речь о функциях не трогающих таблицы, там промежуточные вычисления внутри.
Опять-таки, если она не inlinable — о чём тут говорить?
Ну так а что Вы вообще измеряли, в таком случае? ;) Я, например, именно про них писал и их советовал, если что.
Те SQL functions, которые не inline-атся, могут быть даже хуже, чем plpgsql (или на других PL) — я там писал выше.
> Речь о функциях не трогающих таблицы, там промежуточные вычисления внутри.
Опять-таки, если она не inlinable — о чём тут говорить?
то другой случай) С вычислениями)
Короче у меня видимо каша в голове получилась с этими вариантами)
Короче у меня видимо каша в голове получилась с этими вариантами)
АФ
Yaroslav Schekin
Повысили бы cost, при котором он активируется, зачем сразу голову-то рубить? ;)
я пару раз повысил, он всё равно срабатывал, я плюнул и решил что когда данных будет столько что появятся запросы работающие больше 2 секунд, вернусь к этому вопросу)
YS
А. К.
по типу хинтов в oracle
Никаких hints в PostgreSQL (официально) нет. ;)
Если это возможно (в новых версиях доля планов, которые могут быть parallelized, больше) и планировщик PostgreSQL посчитает (исходя из настроенных costs), что это выгодно — получите параллельный план.
Если это возможно (в новых версиях доля планов, которые могут быть parallelized, больше) и планировщик PostgreSQL посчитает (исходя из настроенных costs), что это выгодно — получите параллельный план.
YS
я пару раз повысил, он всё равно срабатывал, я плюнул и решил что когда данных будет столько что появятся запросы работающие больше 2 секунд, вернусь к этому вопросу)
Странно. Я имею в виду то, что у Вас вообще были "быстрые" запросы с очень большими (если я правильно понял) costs.
Обычно это намекает на другие проблемы с планированием, т.е. можно было бы и посмотреть, откуда такое.
Обычно это намекает на другие проблемы с планированием, т.е. можно было бы и посмотреть, откуда такое.
АК
Yaroslav Schekin
Никаких hints в PostgreSQL (официально) нет. ;)
Если это возможно (в новых версиях доля планов, которые могут быть parallelized, больше) и планировщик PostgreSQL посчитает (исходя из настроенных costs), что это выгодно — получите параллельный план.
Если это возможно (в новых версиях доля планов, которые могут быть parallelized, больше) и планировщик PostgreSQL посчитает (исходя из настроенных costs), что это выгодно — получите параллельный план.
спасибо)
АФ
Yaroslav Schekin
Странно. Я имею в виду то, что у Вас вообще были "быстрые" запросы с очень большими (если я правильно понял) costs.
Обычно это намекает на другие проблемы с планированием, т.е. можно было бы и посмотреть, откуда такое.
Обычно это намекает на другие проблемы с планированием, т.е. можно было бы и посмотреть, откуда такое.
кажется всё дело было в той plpgsql функции)
Надо будет проверить как-нибудь)
Надо будет проверить как-нибудь)
YS
кажется всё дело было в той plpgsql функции)
Надо будет проверить как-нибудь)
Надо будет проверить как-нибудь)
Хмм... может, она у Вас вызывается на каждый row какого-то node плана?
При default cost это примерно 250000 дополнительной стоимости на миллион rows.
Если она на самом деле столько не стоит (узнать можно сравнением с встроенными функциями, например) — можно бы и более "правильную" стоимость ей выставить.
Но это всё предположение, конечно — лучше планы смотреть. :)
При default cost это примерно 250000 дополнительной стоимости на миллион rows.
Если она на самом деле столько не стоит (узнать можно сравнением с встроенными функциями, например) — можно бы и более "правильную" стоимость ей выставить.
Но это всё предположение, конечно — лучше планы смотреть. :)
АФ
Yaroslav Schekin
Хмм... может, она у Вас вызывается на каждый row какого-то node плана?
При default cost это примерно 250000 дополнительной стоимости на миллион rows.
Если она на самом деле столько не стоит (узнать можно сравнением с встроенными функциями, например) — можно бы и более "правильную" стоимость ей выставить.
Но это всё предположение, конечно — лучше планы смотреть. :)
При default cost это примерно 250000 дополнительной стоимости на миллион rows.
Если она на самом деле столько не стоит (узнать можно сравнением с встроенными функциями, например) — можно бы и более "правильную" стоимость ей выставить.
Но это всё предположение, конечно — лучше планы смотреть. :)
она внутри case и вызовов там должно быть в пределах 10.
А реальное время выполнения меньше 1мс
А реальное время выполнения меньше 1мс
YS
она внутри case и вызовов там должно быть в пределах 10.
А реальное время выполнения меньше 1мс
А реальное время выполнения меньше 1мс
Да, планы надо смотреть, в общем. ;)
VH
конкретная проблема в том, что запросы стали обрабатываться дольше в 10-15 раз. Своп есть, но небольшой, память на виртуалке расширили и она практически полностью cached. Как посмотреть насколько приросли таблицы за определенный промежуток времени, я честно говоря хз
А что толку докидывать память на сервак если у Вас work_mem (по дефу стоит 64kB) расходуется на поток .. и он гарантирует вам ваш СВОП...
єто же не сложно .. прописать work_mem = 4MB (к примеру)
посмотреть max_connections помножить одно на второй .. докинуть + 30% и получить объем гарантированно достаточной памяти
єто же не сложно .. прописать work_mem = 4MB (к примеру)
посмотреть max_connections помножить одно на второй .. докинуть + 30% и получить объем гарантированно достаточной памяти
s
Ð
еще вопрос - какой вы ставите рандом кост на ссд?
Условно можно ставить равным косту последовательного доступа при нормальных ssd
YS
Vladimir Holyavik
А что толку докидывать память на сервак если у Вас work_mem (по дефу стоит 64kB) расходуется на поток .. и он гарантирует вам ваш СВОП...
єто же не сложно .. прописать work_mem = 4MB (к примеру)
посмотреть max_connections помножить одно на второй .. докинуть + 30% и получить объем гарантированно достаточной памяти
єто же не сложно .. прописать work_mem = 4MB (к примеру)
посмотреть max_connections помножить одно на второй .. докинуть + 30% и получить объем гарантированно достаточной памяти
> если у Вас work_mem (по дефу стоит 64kB)
The default value is four megabytes (4MB). © documentation
> расходуется на поток
Или не расходуется вообще. Большинству простых запросов она совсем не нужна.
> єто же не сложно .. <skip>
И малополезно, т.к. work_mem — это просто рекомендация (т.е. может вообще игнорироваться) для максимального использования памяти одним узлом плана (если таких одновременно активных узлов, например, 10 — будет использовано в 10 раз больше), используемая при планировании. ;)
Почему Вы вообще решили, что work_mem имеет хоть какое-то отношение к проблеме, в принципе?
The default value is four megabytes (4MB). © documentation
> расходуется на поток
Или не расходуется вообще. Большинству простых запросов она совсем не нужна.
> єто же не сложно .. <skip>
И малополезно, т.к. work_mem — это просто рекомендация (т.е. может вообще игнорироваться) для максимального использования памяти одним узлом плана (если таких одновременно активных узлов, например, 10 — будет использовано в 10 раз больше), используемая при планировании. ;)
Почему Вы вообще решили, что work_mem имеет хоть какое-то отношение к проблеме, в принципе?
VH
ок ... допустим я не прав .. Ваше мнение возникновения свопа?
VH
не в текущей проблеме а в принципе
s
Да что угодно могло попасть в своп, вполне вероятно что это никакого отношения к Постгресу даже не имеет.
Кроме того всё сильно от настроек а-ля vm.swappiness зависит. Может там анонимные страницы при половине свободной оперативки уже начинают вытесняться в своп.
Кроме того всё сильно от настроек а-ля vm.swappiness зависит. Может там анонимные страницы при половине свободной оперативки уже начинают вытесняться в своп.
YS
Vladimir Holyavik
ок ... допустим я не прав .. Ваше мнение возникновения свопа?
Моё мнение — swap не имеет отношения к проблеме вообще, скорее всего.
ВК
@samokhvalov
"I analyzed the contents of pg_stat_statements, collecting snapshots every 15 seconds. The results are in this picture showing Top-5 (by shared_blks_hit) in every 15s interval"
Попроси ребят из gitlub добавить данные по shared_blks_hit / shared_blks_read из pg_stat_statements, чтобы одни взглядом (и на истории) быстро локализовать проблемный запрос.
Пример:
"I analyzed the contents of pg_stat_statements, collecting snapshots every 15 seconds. The results are in this picture showing Top-5 (by shared_blks_hit) in every 15s interval"
Попроси ребят из gitlub добавить данные по shared_blks_hit / shared_blks_read из pg_stat_statements, чтобы одни взглядом (и на истории) быстро локализовать проблемный запрос.
Пример: