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

Question

Я пытаюсь обновить производительность многих представлений для моей работы, и теперь я делаю вещи, как удаление подзапросов, вызовы других функций в select (функции, которые делают выбор внутри), и создание Присоединиться. Я хотел бы знать, имеет ли он правильный выбор, даже думая, что я получу лучшие результаты для получения представления без фильтров (скажем, 20000 строк), не так ясно, что он даст мне лучший результат, скажем, , 200 рядов. Как вы сталкиваетесь с такими взглядами, когда у вас много результатов или что-то происходит, это дорого?

Что еще я могу рассмотреть, чтобы улучшить производительность?

Я искал в некоторых вопросах здесь, и ppl говорят об ортогональном, и я не понимаю. В этой ссылке есть ответ от пользователя jjanes, где он говорит об ортогональном, но это не так понятно. Кто-нибудь знает и может объяснить мне, как «ортогональную» концепцию можно рассматривать с помощью Joins and Subquerys? View doesn't increase performance of correlated subquery?

(Это просто понятие предмет, но я использую Postgre)

Благодаря

Answer 1

Итак, здесь основным ориентиром для оптимизации взглядов (и других длинных запросов) в PostgreSQL.

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

Второе, что нужно понять, это то, что представления инкапсулируют логику данных, и хотя это может показаться хорошей, в ней много ловушек. SQL-программирование прямо противоположно хорошему объектно-ориентированному дизайну в этом отношении, отчасти потому, что SQL является декларативным и отчасти потому, что он строго организован (что делает отладку гораздо более длинного оператора проще, чем сравнительно длинная функция, например, в Python). Итак, нужно сделать следующее: удалить соединения с представлениями в других представлениях.

Представьте себе, например, если у меня есть вид, например, с соединением (что не является чрезмерным, действительно). Но затем я запускаю запрос в представлении с самосоединением. Теперь я перешел от 9 подключений к 81, и проблема не очевидна из-за запроса, вызвавшего проблему (но мальчик, посмотрите на план запроса!).

В целом ваши лучшие виды будут один из трех видов:

1. Простые функции оберток. Например:

   CREATE VIEW current_stock_list AS select * from parts_stock_list(now()); 
   

2. Простые подмножества других таблиц или представлений (но не взглядов оберточной функции), например:

   CREATE VIEW warehouse_current_stock AS select * onhand_stock WHERE warehouse = 1; 
   

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

Надеюсь, это поможет.