Спасибо за книгу. Инструмент, действительно, лучший, я даже не знаю подобных аналогов, а уж "импортозамещенных" - и подавно нет.
Если разработчики выложат этот софт в open-source, то свой продукт точно похоронят - у сторонних разработчиков появится отличная возможность взять best practice продукта и сделать его еще лучше. Т.е. буквально сами себе создадут конкурентов, которых сейчас на рынке нет.
Про postgresql / greenplum - тема для отдельной статьи, т.к. там множество собственных фич - дистрибуция, сжатие, распределение по сегментам, сбор статистики и пр.
Я тоже не сторонник использования hint's, но не упомянуть этот пункт не мог, потому что в отдельных случаях имеет право на жизнь - у нас на 19 оракле до сих пор они есть во многих скриптах. В качестве замены MV можно использовать создание обычных таблиц или представлений с постановкой их на регламентное обновление - в команде именно его и применяем, поскольку нет прав на создание MV с обновлением в режиме ON COMMIT. Но лично мне MV нравятся больше из-за возможности поставить зависимость от изменений таблиц источника без использования дополнительных ETL-инструментов, хоть и отъедают больше ресурсов у БД. Result cache - тема для продвинутых, нужен опыт работы с функциями/пакетами, а целевая аудитория данной статьи вряд ли сможет это корректно применить.
Спасибо за подробный ответ на вопрос выше. На самом деле, без чтения плана тоже вполне можно оптимизировать запрос - пускай и не полноценно. Обычно к теме оптимизации обращаются только тогда, когда запросы уже не отрабатывают или делают это на протяжении десятков минут. В таком случае можно пойти методом исключения - например, поочередно комментить заведомо "подозрительные" (например, таблицы с большим количеством строк, или таблицы без партиций и индексов) соединения таблиц/подзапросов и смотреть на изменения. Этот подход займет больше времени, но для людей, кто видит план запроса по принципу "смотрю в книгу - вижу фигу", он будет под силу.
Данная статья задумывалась изначально как краткий туториал, на что нужно обращать внимание в первую очередь, если запрос перестал адекватно работать, а также как список превентивных мер по минимизации перекосов данных. И если проблему решить сходу не удается - обращаемся к плану, смотрим метаданные связываемых таблиц и т.д.
Спасибо за обратную связь! Если англ.язык - не преграда, то сайт и youtube-канал Берта действительно будут полезны каждому, кто интересуется подобной тематикой
Спасибо за книгу. Инструмент, действительно, лучший, я даже не знаю подобных аналогов, а уж "импортозамещенных" - и подавно нет.
Если разработчики выложат этот софт в open-source, то свой продукт точно похоронят - у сторонних разработчиков появится отличная возможность взять best practice продукта и сделать его еще лучше. Т.е. буквально сами себе создадут конкурентов, которых сейчас на рынке нет.
Про postgresql / greenplum - тема для отдельной статьи, т.к. там множество собственных фич - дистрибуция, сжатие, распределение по сегментам, сбор статистики и пр.
спасибо!
Я тоже не сторонник использования hint's, но не упомянуть этот пункт не мог, потому что в отдельных случаях имеет право на жизнь - у нас на 19 оракле до сих пор они есть во многих скриптах. В качестве замены MV можно использовать создание обычных таблиц или представлений с постановкой их на регламентное обновление - в команде именно его и применяем, поскольку нет прав на создание MV с обновлением в режиме ON COMMIT. Но лично мне MV нравятся больше из-за возможности поставить зависимость от изменений таблиц источника без использования дополнительных ETL-инструментов, хоть и отъедают больше ресурсов у БД. Result cache - тема для продвинутых, нужен опыт работы с функциями/пакетами, а целевая аудитория данной статьи вряд ли сможет это корректно применить.
Спасибо за подробный ответ на вопрос выше. На самом деле, без чтения плана тоже вполне можно оптимизировать запрос - пускай и не полноценно. Обычно к теме оптимизации обращаются только тогда, когда запросы уже не отрабатывают или делают это на протяжении десятков минут. В таком случае можно пойти методом исключения - например, поочередно комментить заведомо "подозрительные" (например, таблицы с большим количеством строк, или таблицы без партиций и индексов) соединения таблиц/подзапросов и смотреть на изменения. Этот подход займет больше времени, но для людей, кто видит план запроса по принципу "смотрю в книгу - вижу фигу", он будет под силу.
Данная статья задумывалась изначально как краткий туториал, на что нужно обращать внимание в первую очередь, если запрос перестал адекватно работать, а также как список превентивных мер по минимизации перекосов данных. И если проблему решить сходу не удается - обращаемся к плану, смотрим метаданные связываемых таблиц и т.д.
Спасибо за обратную связь! Если англ.язык - не преграда, то сайт и youtube-канал Берта действительно будут полезны каждому, кто интересуется подобной тематикой
Спасибо за вашу оценку!