Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 15
Наконец-то, жаль пользоваться этим на текущей инфраструктуре не выйдет, Гугл ещё сто лет будет cloud sql обновлять.
Почему бы это как хинт не сделать, как в оракле?
We are not interested in implementing hints in the exact ways they are commonly implemented on other databases.
Зачем делать «как хинт» то, что можно сделать (и, в итоге, сделано) элементом нормального синтаксиса?
Все таки это указание оптимизатору.
С одной стороны — логично. С другой — в аналогичной ситуации с материализованными представлениями факт требования материализации — тоже, в известной степени, указание оптимизатору.
По материализованным представлениям можно строить индексы.
Строго говоря оптимизатор может делать индексы по любым промежуточным резалтсетам (и у вас, как правило, нет никакой возможности на это повлиять). На что это влияет?
По сути, когда вы создаёте материализованное представление вы создаёте (и хотите создать) таблицу. Просто у неё такой синтаксис специальный :) То же самое получается и здесь. С той лишь разницей что таблица эта — временная.
По сути, когда вы создаёте материализованное представление вы создаёте (и хотите создать) таблицу. Просто у неё такой синтаксис специальный :) То же самое получается и здесь. С той лишь разницей что таблица эта — временная.
Не-не, не путайте.
Не может. Индекс можно построить только по таблице (ну или по материализованному представлению, что суть почти одно и то же) и только вручную. Оптимизатор ничего такого сам по себе никогда не делает.
Материализация CTE и материализованное представление — это две совсем разные штуки.
Материализация CTE состоит в том, что результат CTE запоминается (на время выполнения запроса) и может быть использован в дальнейших соединениях и других операциях. Никакая временная таблица для этого не создается. Если результат CTE помещается в память (work_mem), то в памяти он и сидит. Если не помещается — скидывается на диск, но не в таблицу, а в какой-то служебный файлик, а-ля своп.
оптимизатор может делать индексы по любым промежуточным резалтсетам
Не может. Индекс можно построить только по таблице (ну или по материализованному представлению, что суть почти одно и то же) и только вручную. Оптимизатор ничего такого сам по себе никогда не делает.
То же самое получается и здесь. С той лишь разницей что таблица эта — временная.
Материализация CTE и материализованное представление — это две совсем разные штуки.
Материализация CTE состоит в том, что результат CTE запоминается (на время выполнения запроса) и может быть использован в дальнейших соединениях и других операциях. Никакая временная таблица для этого не создается. Если результат CTE помещается в память (work_mem), то в памяти он и сидит. Если не помещается — скидывается на диск, но не в таблицу, а в какой-то служебный файлик, а-ля своп.
Оптимизатор ничего такого сам по себе никогда не делает.Возможно оптимизатор PostgreSQL (в текущих версиях) этого не делает, но другие делают (и, вероятно, он тоже будет).
Материализация CTE и материализованное представление — это две совсем разные штуки.В чём именно состоит принципиальная разница? И там, и там получается кортеж, которых сохраняется (там, куда помещается). Вы, вероятно, слишком узко рассматриваете понятие «временная таблица».
Другие делают? Пример в студию!
Принципиальная разница в том, что в одном случае мы имеем дело с объектом базы данных в системном каталоге, а в другом — нет. А так-то да, можно что угодно свести к набору кортежей.
Принципиальная разница в том, что в одном случае мы имеем дело с объектом базы данных в системном каталоге, а в другом — нет. А так-то да, можно что угодно свести к набору кортежей.
Как вариант, чтобы работало быстро в 12-й версии, и возможно медленно но работало в 11-й.
Но разработчики PG давно выбрали вариант с частью синтаксиса, пусть уж лучше однообразно будет (кстати у oracle materialize не единственное что можно сделать с подзапросом, в т.ч. из view, что на мой взгляд иногда помогает весьма гибко направлять оптимизатор не создавая новые view).
Наконец-то разделяются управление сложностью запроса и управление работой с данными в ходе выполнения запроса.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Важные изменения в работе CTE в PostgreSQL 12