Руководство по созданию эффективных запросов

в
ременные
 
таБлиЦы
 
и
 
оБщие
 
таБличные
 
выражения
В главе 6 мы упоминали, что иногда попытка разработчиков SQL ускорить 
выполнение запроса, наоборот, может привести к замедлению. Такое часто 
случается, когда они решают использовать 
временные
таблицы
.
Временные таблицы
Чтобы создать временную таблицу, нужно выполнить обычную команду 
crea-
te
table
, добавив ключевое слово 
temporary
или просто 
temp
:
CREATE TEMP TABLE interim_results
Временные таблицы видны только текущему сеансу и удаляются при его 
завершении, если не были явно удалены до этого. В остальном они ничем не 
уступают обычным таблицам: их можно использовать в запросах без всяких 
ограничений и даже можно индексировать. Временные таблицы часто ис-
пользуются для хранения промежуточных результатов запросов, поэтому 
команда 
CREATE
нередко выглядит так:
CREATE TEMP TABLE interim_results AS
SELECT ...
Это смотрится очень удобно, так что же плохого в таком подходе?
Все это отлично работает, если вы сохраняете результаты своего запроса 
во временной таблице для некоего анализа, а затем удаляете ее. Но если ис-
пользовать временные таблицы для хранения результатов каждого шага, код 
начинает выглядеть так:
CREATE TEMP TABLE T1 AS
SELECT ...;
CREATE TEMP TABLE T2 AS
SELECT ...
FROM T1 INNER JOIN ...
...

---

136

Длинные запросы: дополнительные приемы
Цепочка временных таблиц может стать довольно длинной. Вызывает ли 
это какие-то проблемы? Да, и много, в том числе следующие:
 

индексы
– после того как выбранные данные будут сохранены во вре-
менной таблице, мы не можем использовать индексы, созданные в ис-
ходной таблице (или таблицах). Нам либо придется обойтись без индек-
сов, либо создать новые во временных таблицах, что требует ресурсов;
 

статистика
– поскольку мы создали новую таблицу, оптимизатор не 
может использовать статистические данные о распределении значе-
ний из исходной таблицы (или таблиц), поэтому нам придется либо 
обойтись без статистики, либо выполнить команду 
ANALYZE
для вре-
менной таблицы;
 

место
на
диске
– когда промежуточные результаты не помещаются 
в доступную оперативную память, временные таблицы сохраняются 
на диске. Как бы маловероятно это ни звучало, мы наблюдали ситуа-
ции, когда большие запросы, использующие соединения, сортировки 
и группировки, конкурировали за пространство с временными табли-
цами, в результате чего запросы отменялись;
 

чрезмерный
ввод-вывод
– временные таблицы – это таблицы, и они мо-
гут быть записаны на диск, а для записи на диск и чтения с диска тре-
буется дополнительное время.
Но наиболее важным отрицательным следствием чрезмерного использо-
вания временных таблиц является то, что такая практика не дает оптимиза-
тору переписывать запросы.
Сохраняя результаты каждого соединения во временную таблицу, вы не 
позволяете оптимизатору выбирать оптимальный порядок соединений; вы 
фиксируете тот порядок, в котором создаете временные таблицы.
Когда мы рассматривали план выполнения запроса из лис тинга 6.15, то за-
метили, что PostgreSQL может переместить условие фильтрации на уровень 
группировки. Что произойдет, если для промежуточных результатов будет 
создана временная таблица?