Comments 28
Черт! Это действительно круто! Я очень рад.
Да — это круто!
Да — я тоже рад!
Но!!!
Было бы намного круче и радостнее, если бы хинты сделали совместимыми с оракловыми.
Да — я тоже рад!
Но!!!
Было бы намного круче и радостнее, если бы хинты сделали совместимыми с оракловыми.
Нужно делать скидку на то, что хинты реализованы в виде модуля, что накладывает определенные ограничения (лично я вообще удивился тому, что это оказалось возможно). А в ядро их не очень-то хотят добавлять.
UFO just landed and posted this here
SQL — декларативный язык, он указывает, «что» мы хотим выбрать из базы, а «как» это сделать — база решает сама. Эту задачу в базе решает планировщик. Но иногда он выбирает не самый лучший способ выполнить запрос. «Хинты» позволяют в ручном режиме подсказывать базе, как лучше выполнить запрос.
UFO just landed and posted this here
Пост написан для тех, кто, как говориться, уже «в теме». Советую начать, например, вот с этой презентации.
Интересно, спасибо.
Оно и понятно. Такой тонкий тюнинг вряд ли когда пригодится, практически это значит, что всё остальное оптимизировано почти до совершенства. А как показывает практика, узкие места всплывают везде, если копнуть.
Этим я хотел намекнуть на то, что стоит два раза подумать, прежде чем использовать хинты в реальных проектах.
Оно и понятно. Такой тонкий тюнинг вряд ли когда пригодится, практически это значит, что всё остальное оптимизировано почти до совершенства. А как показывает практика, узкие места всплывают везде, если копнуть.
Не, ну еще есть откровенные загоны планировщика в конкретных местах. Так что очень даже ура!
Может быть, не спорю, хотя сам с прямо конкретными загонами не сталкивался.
Вот здесь можете ознакомиться. Хотя это не загон, а скорее особенность.
Мы в Оракле его часто используем. Не исключено, что и в Постргресе где-то пригодится.
Идея хорошая, но да, навевает сомнения в использовании в реальных проектах )
С другой стороны, можно одни и те же результаты выборки получать несколько по разному формируя запрос и тем самым вызывая разные Scan'ы
С другой стороны, можно одни и те же результаты выборки получать несколько по разному формируя запрос и тем самым вызывая разные Scan'ы
Спасибо за статью. Подскажите, с какими параметрами производили установку? У меня
фейлится.
make USE_PGXS=1 PG_CONFIG=/usr/local/pgsql/bin/pg_config
фейлится.
Лучше бы докомошники партиционирование нормальное впилили или MPP. Или хинты по чилдам: «не чекай 100500 чилдов на constraint exclusion, а сразу топай к таким то» или SQL/MED допиливали быстрее, причем с оптимизацией выполнения запросов для PG-PG связки. Вообщем хочу PostgresXC взрослый и в основном бранче.
А «хинты» и до этого были: «SET enable_seqscan=OFF;» работает в сессии. Можно набор функций по сохранению/включению/выключению допилить и вуаля. Причем профит в том что не указываешь, как именно надо делать, а показываешь чего делать не стоит.
Хотя если честно ни разу не сталкивался еще с тем, что ручное указание плана при правильной статистике дало профит. Всегда это было или криво сконфигуреный автоваакуум/аналайз, или проблемы с индексами, или кривая структура. Планировщик в PG достаточно эффективный.
А «хинты» и до этого были: «SET enable_seqscan=OFF;» работает в сессии. Можно набор функций по сохранению/включению/выключению допилить и вуаля. Причем профит в том что не указываешь, как именно надо делать, а показываешь чего делать не стоит.
Хотя если честно ни разу не сталкивался еще с тем, что ручное указание плана при правильной статистике дало профит. Всегда это было или криво сконфигуреный автоваакуум/аналайз, или проблемы с индексами, или кривая структура. Планировщик в PG достаточно эффективный.
Судя по исходному коду, эта штука просто использует существовавшие и до этого параметры сессии: enable_seqscan, enable_indexscan, enable_bitmapscan, enable_tidscan и т.д., просто оборачивает их в подобие oracle hints
Хотелось бы всё-таки увидеть пример положительного использования хинтов. Но, думаю, если планировщик можно обмануть (заставить выполнить запрос не оптимально), то нужно писать багрепорт.
Положительный пример постараюсь привести. Обмануть планировщик вполне возможно, т.к.:
- Не учитываются всевозможные корреляции, и их учесть — очень трудная задача, пока не понятно как её решать.
- Для ряда типов и операций адекватных оценок селективности нет.
Прикольная тулза, пример реальный простой. запрос с кучей join как inner так и left, в конце сортировка и лимитирование, сортировка по полю из таблицы указанной во from, а не в joun'ах. Используя Leading в корне меняем результат:
1. сбор данных, сортировка, лимитирование
2. сбор данных, лимитирование
причем без Leading игры с =off разных фич планировщика не помогали.
1. сбор данных, сортировка, лимитирование
2. сбор данных, лимитирование
причем без Leading игры с =off разных фич планировщика не помогали.
Sign up to leave a comment.
Хинты планера в PostgreSQL