День добрый. Есть отчёт:срез последних скидок, отбор порядка 50к строк. MSSQL:

исполнение ~40сек
PostgresSQL: исполнение более 50 минут
Проблема только с этим отчётом. В остальном PG быстрее MS ~50%
Проблема в том, что запрос не оптимальный или в PG во что то упирается?

Тот случай, когда в вопросе уже ответ. Как думаете, если проблема только в одном отчете, то какова вероятность, что проблема в ресурсах для ПГ? ПС: Сделайте замер, возможно сразу покажет на каком запросе проседает(если их много или пакетник), далее снимайте план запроса, находите проблемный этап и отдавайте на оптимизацию кодерам.

Не оптимальный. Упирается если разница в разы, а тут 60 раз

Analyze делали?

“В остальном PG быстрее MS ~50%” - на том же железе?

Почему нет? Старая база мсскл в которой не включено обслуживание против свежесозданной постгре

Да вот я про это тоже

В принципе баш на баш на упр блокировках

без конфигов сервера и плана запроса ТОЛЬКО пальцем в небо. как пример нехватка work_mem приводит к сбросу на диск данных, что в зависимости от скорости диска может очень сильно замедлить выполнение. неверная статистика или цена random page cost может приводить к seq_scan и т.д.

Или просто постгре неправильно подсчитал стоимость запроса и сделал нестлуп

Seqscan 50 минут? Что там за база огромная?

Toast?

> в зависимости от скорости диска В независимости. Если оно влезет в память -- оно будет в pagecache линукса, пусть этим данным и назначен файл. Если оно не влезет в память -- его выкинет в swap, хоть там work_mem и хватит. Разница в скорости доступа к дисковой структуре и структуре в памяти есть. Можэт, раза в два дажэ (почти всегда меньшэ). Но не надо думать, что с временными файлами на диске тут всё плохо (или с операцыями в памяти всегда всё хорошо).

для начала запрос в студию

И когда делался Analyze, reindex, vacuum full

я немного сумбурно описал то, с чем сталкивался, на ssd пока не подкрутил random_page_cost со стандартных значений в 4, индексы частенько не использовались. пока work_mem был низкий, соответствующие запросы судя по плану сбрасывали на диск.

Каждый божий день=)

Два дня назад

Прирост из-за более производительного железа

Запрос: https://controlc.com/46893168

переписать на временные таблицы https://its.1c.ru/db/metod8dev#content:5842:hdoc:vtable_join

Если не сложно, просветите, почему так происходит? При использовании временной таблицы запрос одинаково быстро работает в PG и MSSQL

Поместить во временные таблицы срезы ну или попробовать вложить их во вложенные запросы

вряд ли вложенные запросы улучшат ситуацию.

Помогают. Проверено, но не всегда. Тут соединяется 8 таблиц. Постгре просто путается в плане соединения.

дак подзапросы так же хреново соединяются между собой. вообщем "резать к чертовой матери, не дожидаясь перитонита!"

В плане насколько я помню вначале пытается объединить вложенные

Дело в том, что в отличии от мсскл если запрос помещается во временную таблицу, то он всегда выполняется в один поток

по той же ссылке https://its.1c.ru/db/metod8dev#content:5842:hdoc:subquery_join :) вообщем может и поможет, а может и нет. зачем рисковать?

Хреновый совет

чем хреновый?

Мы всегда читаем весь регистр сведений

вы про рекомендацию избегать соединения подзапросов или про рефакторинг данного куска?

Про рефакторинг

в данном случае нет фильтров по номенклатуре и не ясно какая будет выборка. если известно что в скидках позиций существенно меньше - можно сначала сделать времнную по ним, а получение цен сделать с отбором по тем позициям где есть скидки.

Если запрос большой, то так не придумаешь и лучше полагаться на оптимизатор.

да, в любом случае надо от конкретной задачи исходить.

Ага. В простом случае(работа до минуты отчёта) лучше временные однозначно.

Вообще в плане, точнее до не него оптимизатоп жонглирует соединениями как ему виднее, поэтому под запросы в контексте пг абсолютно такие же, за редким исключением вроде группировок, что без под запроса.

А где это написано?

В документации и курсах, в dba-1 насколько я помню было

Это для мсскл или постгре?

Пг

Ниже сделал тест. Смотрите ) Подзапросы сохраняют порядок

одно исполнение не показатель.

12 подзапросы не разрушаются

хорошо если так, но я бы не стал на это серьезно рассчитывать. 1) есть рекмоендация вендора так не делать 2) в будущем через 2-3-10 лет может смениться и поведение СУБД и вообще сама СУБД.

Через 10 лет люди ещё останутся?

Это значит, что такой порядок оптимизатор устраивает

В оракле вроде было правило, если найденный план не сильно лучше естественному (порядок записи в запросе) то применяется естественный

я про оракл ничего не писал.

Просто вспомнил )

лень же вам одну страницу прочитать https://postgrespro.ru/docs/postgresql/15/planner-optimizer

Читал. Нигде не нашел, что вложенные раскрываются

сделайте неэффективный внутренний запрос и проверьте, у меня нет желания вам что-то доказывать. увидите что select t1 join (select t2 join t3) от select t1 join t2 join t3 ничем не отличается, если нет например агрегатных функций или группировок