Классика баз данных - статьи

       

Такая повторная оптимизация усложняется для


Такая повторная оптимизация усложняется для более сложных планов запросов с несколькими точками материализации. В [12] предлагается оформлять TEMP в виде таблиц и преобразовывать часть плана запроса, оставшуюся после формирования TEMP, в SQL-запрос, который снова передается оптимизатору запросов. К сожалению, у этого подхода имеются два недостатка. Во-первых, может оказаться, что использование таблиц TEMP в том виде, в каком они существуют, не является оптимальным. В тех случаях, когда размер TEMP оказывается намного больше, чем предполагалось, в оптимальном плане может повторно использоваться только часть TEMP, или TEMP может вообще полностью игнорироваться, если в полностью новом плане напрямую используются базовые таблицы. Во-вторых, часть плана, оставшуюся после формирования TEMP, не всегда можно выразить в виде оператора SQL, особенно в этой части содержатся операции обновления, возникающие по причине наличия подзапросов.

Более хороший подход состоит в том, чтобы не оформлять TEMP в виде таблиц, а определять их как материализованные представления [13] (в DB2 их называют Automatic Summary Table [14]) и предоставлять их определения оптимизатору запросов. Тогда оптимизатор может опираться на стандартные методы проверки соответствия представлений [15] для определения того, какие TEMP стоит использовать повторно. Затраты на повторную оптимизацию с использованием дополнительных материализованных представлений практически идентичны затратам на оптимизацию исходного запроса, поскольку от оптимизатора требуется всего лишь рассмотрение одного альтернативного метода доступа к промежуточной таблице для каждого материализованного представления.

Более того, если TEMP определяются в виде материализованных представлений, нет оснований ограничивать их использование только текущим запросом. Материализованные TEMP потенциально могут использоваться во всех последующих запросах таким же образом, как в них используются материализованные представления, определенные пользователями.Конечно, этот подход может привести к лавинообразному росту числа таких представлений, поэтому процессор запросов должен периодически удалять редко используемые представления; это сродни проблеме подвыбора материализованных представлений [16].


Содержание  Назад  Вперед