Consultas utilizando SQL Query Engine

El motor de SQL Query (SQE) proporciona optimización de destino para tablas particionadas utilizando la optimización de expansión de partición dinámica.

Este método de optimización de destino primero determina si una consulta determinada está estructurada de tal forma que determinadas particiones de la tabla particionada se beneficiarían de una optimización específica. Si se garantiza la optimización de destino, el optimizador determina qué particiones pueden beneficiarse de la optimización individual; a continuación, estas particiones se optimizan por separado. Las particiones restantes utilizan la técnica una vez para todos los .

Si la expansión está justificada, el optimizador determina las particiones de destino utilizando las técnicas de estadísticas existentes según corresponda. Por ejemplo, para el particionamiento de rangos y la selección de predicados, el optimizador busca en las estadísticas o en el índice para determinar qué particiones principales son de interés. Cuando se identifican las particiones de destino, el optimizador reescribe la consulta. Las particiones de destino se redefinen en una operación UNION. Las particiones restantes permanecen como una instancia de tabla única. A continuación, esta instancia única se añade a la operación UNION junto con las particiones de destino. Tan pronto como se realiza la reescritura, el optimizador utiliza las técnicas de optimización existentes para determinar el plan para cada pieza UNION. Al final de la optimización, la instancia única se convierte en otra operación UNION de sus particiones contenidas. El plan optimizado para la instancia única se replica en los subárboles UNION, lo que reduce drásticamente el tiempo de optimización para las tablas particionadas.

El motor de SQL Query también utiliza la eliminación de particiones lógicas para optimizar las tablas particionadas. Este método permite al optimizador identificar posibles oportunidades de eliminación de particiones. El optimizador busca oportunidades en las que el conjunto de respuestas reducido de una tabla de origen se puede aplicar a la clave de definición de la tabla de partición con un predicado de unión. Cuando se identifican estas oportunidades, el optimizador crea lógica en el tiempo de ejecución de la consulta para eliminar particiones basándose en el conjunto de resultados de la tabla de origen.

Por ejemplo, considere una consulta en la que el optimizador identifica un predicado (en este ejemplo, una cláusula WHERE) que implica la clave de partición de la tabla de partición. Si una restricción en una partición limita la clave a un rango de 0 a 10 y un predicado en la consulta identifica un valor de clave de 11, la partición se puede eliminar lógicamente. Tenga en cuenta que la implementación de la partición se sigue incorporando en la consulta, pero el proceso inicial de la restricción combinada con el predicado desvía la vía de acceso. Esta lógica se incorpora con fines de reutilización. Otra consulta con un predicado que identifica un valor clave de 10 también se puede implementar con este plan. Si la partición se eliminara físicamente de la implementación, la implementación no sería reutilizable.

Considere este ejemplo más complicado:

select *
from sales, timeDim
where sales.DateId = timeDim.DateId
and timeDim.Date > '09/01/2004'

En este ejemplo, sales es una tabla particionada por rangos donde sales.DateId se identifica como la clave de partición y sales.DateId = timeDim.DateId se identifica como un predicado de reducción potencial. La consulta se modifica (aproximadamente) como:

with sourceTable as (select * from timeDim where  timeDim.Date > '09/01/2004')
select *
from sales, sourceTable
where sales.DateId = sourceTable.DateId
and sales.DateId IN (select DateId from sourceTable)