Как стать автором
Обновить

Комментарии 12

А разве планы запросов из PL/pgSQL не кэшируются всегда?
PL/pgSQL всегда использует подготовленные операторы, это да. То есть можно сказать, что всегда кэшируется разобранный запрос. Но разобранный запрос — это еще не план. План будет строиться каждый раз заново до тех пор, пока планировщик не сочтет, что «общий» план не хуже тех «частных», которые он до сих пор строил.
А глобального кэша все равно не существует?
Если так, то получается, что высоконагруженный OLTP без использования пула с очень долгим временем жизни соединений нельзя строить в принципе.
Глобального кэша не существует, подготовленные операторы живут в памяти процессов, обслуживающих соединения.
С другой стороны, отсутствие глобального кэша удешевляет разбор.
А насчет того, можно или нельзя строить высоконагруженные системы — это надо тестировать и смотреть, я так считаю.
Спасибо, интересно было почитать про реализацию в PostreSQL.
Насчет Oracle пара поправок:
Поэтому (начиная с версии 11g) Оракл умеет находить и специально обрабатывать запросы, чувствительные к значениям переменных связывания (это называется «adaptive cursor sharing»). При выполнении запроса используется уже имеющийся в кэше план, но отслеживаются реально затраченные ресурсы и сравниваются со статистикой предыдущих выполнений.

оцениваются не ресурсы, а сами входные значения bind variables (см. v$sql_cs_histogram)
Помимо этого у Oracle есть еще механизмы уточнения/исправления плана в случае ошибки вычисления cardinality — dynamic sampling и cardinality feedback.
А с 12-й версии появился новый механизм adaptive plans — который позволяет изменить план прямо во время выполнения, в случае высокой погрешности estimated cardinality от реальной
Интересно, что команда explain plan (результат которой доступен с помощью функции dbms_xplan.display) все равно покажет план, построенный из предположения равномерности, как будто оптимизатор ожидает получения половины таблицы...
Просто в отличие от PostreSQL в Oracle никак нельзя вызвать explain plan с указанием bind variables (к сожалению...)
Про v$sql_cs_histogram не знал, спасибо!
Оракловый оптимизатор, без всякого сомнения, на порядок более сложно устроен и умеет много такого, до чего Постгресу расти еще очень долго — там пока все довольно просто. Но он растет.
Да и я рад что растет, причем хочется чтобы в дальнейшем совместимость с Oracle возрастала. Буквально вчера узнал что в MySQL появились хинты и 2-3 из них даже с такими же именами как в Oracle — хочу такого же и для PostreSQL :)
О, хинты — это больная тема… Разработчики оптимизатора не хотят их добавлять (и их в принципе можно понять, по моему опыту хинты часто втыкают просто от нежелания разобраться и найти нормальное решение), но есть расширения на эту тему.
да, знаю про расширение, но у меня несколько другая позиция — я считаю, что есть достаточное кол-во хороших разработчиков, которые сами прекрасно знают как запрос лучше выполнять. Нужно оставлять разработчикам возможность более низкоуровневого доступа.
Не надо путать в Oracle soft parse и вызов готового запроса по дескриптору. Когда выполняется правильный цикл в PL/SQL, происходит именно это. Soft parse по сравнению с hard parse ускоряет исполнение не так радикально.
Ъ! Да, этот момент я упустил из виду, спасибо.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий