19.7. Planificación de consultas #

19.7.1. Configuración de los métodos del planificador
19.7.2. Constantes de coste del planificador
19.7.3. Optimizador genérico de consultas (Genetic Query Optimizer)
19.7.4. Otras opciones del planificador

19.7.1. Configuración de los métodos del planificador #

Estos parámetros de configuración proporcionan un método aproximado para influir en los planes de consulta elegidos por el optimizador. Si el plan predeterminado elegido por el optimizador para una consulta en particular no es el óptimo, una solución temporal es utilizar uno de estos parámetros de configuración para forzar al optimizador a elegir un plan diferente. Las mejores formas de mejorar la calidad de los planes elegidos por el optimizador incluyen ajustar las constantes de coste del planificador (consulta la Section 19.7.2), ejecutar ANALYZE manualmente, aumentar el valor del parámetro de configuración default_statistics_target, y aumentar la cantidad de estadísticas recopiladas para columnas específicas mediante ALTER TABLE SET STATISTICS.

enable_async_append (boolean) #

Habilita o deshabilita el uso por parte del planificador de consultas de tipos de planes de anexado con reconocimiento de asincronía (async-aware append). El valor predeterminado es on.

enable_bitmapscan (boolean) #

Habilita o deshabilita el uso por parte del planificador de consultas de tipos de planes de escaneo de mapa de bits. El valor predeterminado es on.

enable_distinct_reordering (boolean) #

Habilita o deshabilita la capacidad del planificador de consultas para reordenar las claves DISTINCT para que coincidan con las pathkeys de la ruta de entrada. El valor predeterminado es on.

enable_gathermerge (boolean) #

Habilita o deshabilita el uso por parte del planificador de consultas de tipos de planes de reunión de fusión (gather merge). El valor predeterminado es on.

enable_group_by_reordering (boolean) #

Controla si el planificador de consultas producirá un plan que proporcionará claves GROUP BY ordenadas en el orden de las claves de un nodo hijo del plan, como un escaneo de índice. Cuando está deshabilitado, el planificador de consultas producirá un plan con claves GROUP BY ordenadas solo para coincidir con la cláusula ORDER BY, si la hay. Cuando está habilitado, el planificador intentará producir un plan más eficiente. El valor predeterminado es on.

enable_hashagg (boolean) #

Habilita o deshabilita el uso por parte del planificador de consultas de tipos de planes de agregación basada en hash. El valor predeterminado es on.

enable_hashjoin (boolean) #

Habilita o deshabilita el uso por parte del planificador de consultas de tipos de planes de unión hash (hash-join). El valor predeterminado es on.

enable_incremental_sort (boolean) #

Habilita o deshabilita el uso por parte del planificador de consultas de pasos de ordenación incremental. El valor predeterminado es on.

enable_indexscan (boolean) #

Habilita o deshabilita el uso por parte del planificador de consultas de tipos de planes de escaneo de índice (index-scan) y escaneo de solo índice (index-only-scan). El valor predeterminado es on. Consulta también la enable_indexonlyscan.

enable_indexonlyscan (boolean) #

Habilita o deshabilita el uso por parte del planificador de consultas de tipos de planes de escaneo de solo índice (consulta la Section 11.9). El valor predeterminado es on. La configuración enable_indexscan también debe estar habilitada para que el planificador de consultas considere los escaneos de solo índice.

enable_material (boolean) #

Habilita o deshabilita el uso de la materialización por parte del planificador de consultas. Es imposible suprimir la materialización por completo, pero desactivar esta variable evita que el planificador inserte nodos de materialización excepto en los casos en que sea necesario para la corrección. El valor predeterminado es on.

enable_memoize (boolean) #

Habilita o deshabilita el uso por parte del planificador de consultas de planes de memoización para almacenar en caché los resultados de los escaneos parametrizados dentro de las uniones de bucle anidado (nested-loop joins). Este tipo de plan permite omitir los escaneos a los planes subyacentes cuando los resultados para los parámetros actuales ya están en la caché. Los resultados consultados con menos frecuencia pueden ser desalojados de la caché cuando se requiere más espacio para nuevas entradas. El valor predeterminado es on.

enable_mergejoin (boolean) #

Habilita o deshabilita el uso por parte del planificador de consultas de tipos de planes de unión por fusión (merge-join). El valor predeterminado es on.

enable_nestloop (boolean) #

Habilita o deshabilita el uso por parte del planificador de consultas de planes de unión de bucle anidado (nested-loop join). Es imposible suprimir las uniones de bucle anidado por completo, pero desactivar esta variable desaconseja al planificador utilizarlas si hay otros métodos disponibles. El valor predeterminado es on.

enable_parallel_append (boolean) #

Habilita o deshabilita el uso por parte del planificador de consultas de tipos de planes de anexado con reconocimiento de paralelismo (parallel-aware append). El valor predeterminado es on.

enable_parallel_hash (boolean) #

Habilita o deshabilita el uso por parte del planificador de consultas de tipos de planes de unión hash con hash paralelo. No tiene efecto si los planes de unión hash no están también habilitados. El valor predeterminado es on.

enable_partition_pruning (boolean) #

Habilita o deshabilita la capacidad del planificador de consultas para eliminar las particiones de una tabla particionada de los planes de consulta. Esto también controla la capacidad del planificador para generar planes de consulta que permitan al ejecutor de consultas eliminar (ignorar) particiones durante la ejecución de las consultas. El valor predeterminado es on. Consulta la Section 5.12.4 para obtener más detalles.

enable_partitionwise_join (boolean) #

Habilita o deshabilita el uso por parte del planificador de consultas de la unión por particiones (partitionwise join), que permite realizar una unión entre tablas particionadas mediante la unión de las particiones coincidentes. La unión por particiones actualmente se aplica solo cuando las condiciones de unión incluyen todas las claves de partición, las cuales deben ser del mismo tipo de datos y tener conjuntos coincidentes uno a uno de particiones hijas. Con esta configuración habilitada, el número de nodos cuyo uso de memoria está restringido por work_mem que aparecen en el plan final puede aumentar linealmente de acuerdo con el número de particiones que se están escaneando. Esto puede resultar en un gran aumento en el consumo general de memoria durante la ejecución de la consulta. La planificación de la consulta también se vuelve significativamente más costosa en términos de memoria y CPU. El valor predeterminado es off.

enable_partitionwise_aggregate (boolean) #

Habilita o deshabilita el uso por parte del planificador de consultas de la agrupación o agregación por particiones (partitionwise grouping/aggregation), que permite realizar la agrupación o agregación en tablas particionadas por separado para cada partición. Si la cláusula GROUP BY no incluye las claves de partición, solo se puede realizar una agregación parcial en cada partición y la finalización debe realizarse más tarde. Con esta configuración habilitada, el número de nodos cuyo uso de memoria está restringido por work_mem que aparecen en el plan final puede aumentar linealmente de acuerdo con el número de particiones que se están escaneando. Esto puede resultar en un gran aumento en el consumo general de memoria durante la ejecución de la consulta. La planificación de la consulta también se vuelve significativamente más costosa en términos de memoria y CPU. El valor predeterminado es off.

enable_presorted_aggregate (boolean) #

Controla si el planificador de consultas producirá un plan que proporcionará filas que están preordenadas en el orden requerido para las funciones agregadas ORDER BY / DISTINCT de la consulta. Cuando está deshabilitado, el planificador de consultas producirá un plan que siempre requerirá que el ejecutor realice una ordenación antes de realizar la agregación de cada función agregada que contenga una cláusula ORDER BY o DISTINCT. Cuando está habilitado, el planificador intentará producir un plan más eficiente que proporcione entrada a las funciones agregadas que esté preordenada en el orden que requieren para la agregación. El valor predeterminado es on.

enable_self_join_elimination (boolean) #

Habilita o deshabilita la optimización del planificador de consultas que analiza el árbol de consulta y reemplaza las autouniones (self joins) con escaneos individuales semánticamente equivalentes. Toma en consideración únicamente tablas simples. El valor predeterminado es on.

enable_seqscan (boolean) #

Habilita o deshabilita el uso por parte del planificador de consultas de tipos de planes de escaneo secuencial. Es imposible suprimir los escaneos secuenciales por completo, pero desactivar esta variable desaconseja al planificador utilizarlos si hay otros métodos disponibles. El valor predeterminado es on.

enable_sort (boolean) #

Habilita o deshabilita el uso por parte del planificador de consultas de pasos de ordenación explícitos. Es imposible suprimir las ordenaciones explícitas por completo, pero desactivar esta variable desaconseja al planificador utilizarlas si hay otros métodos disponibles. El valor predeterminado es on.

enable_tidscan (boolean) #

Habilita o deshabilita el uso por parte del planificador de consultas de tipos de planes de escaneo TID. El valor predeterminado es on.

19.7.2. Constantes de coste del planificador #

Las variables de coste descritas en esta sección se miden en una escala arbitraria. Solo importan sus valores relativos, por lo tanto, escalarlas todas hacia arriba o hacia abajo por el mismo factor no producirá ningún cambio en las elecciones del planificador. De forma predeterminada, estas variables de coste se basan en el coste de las lecturas secuenciales de páginas; es decir, seq_page_cost se establece convencionalmente en 1.0 y las otras variables de coste se establecen con referencia a eso. Pero puedes usar una escala diferente si lo prefieres, como los tiempos de ejecución reales en milisegundos en una máquina en particular.

Note

Desafortunadamente, no existe un método bien definido para determinar los valores ideales de las variables de coste. Es mejor tratarlos como promedios sobre toda la mezcla de consultas que recibirá una instalación en particular. Esto significa que cambiarlos sobre la base de solo unos pocos experimentos es muy arriesgado.

seq_page_cost (floating point) #

Establece la estimación del planificador del coste de una lectura de página de disco que forma parte de una serie de lecturas secuenciales. El valor predeterminado es 1.0. Este valor se puede anular para tablas e índices en un tablespace particular configurando el parámetro de tablespace del mismo nombre (consulta la ALTER TABLESPACE).

random_page_cost (floating point) #

Establece la estimación del planificador del coste de una lectura de página de disco obtenida de forma no secuencial. El valor predeterminado es 4.0. Este valor se puede anular para tablas e índices en un tablespace particular configurando el parámetro de tablespace del mismo nombre (consulta la ALTER TABLESPACE).

Reducir este valor en relación con seq_page_cost hará que el sistema prefiera los escaneos de índice; elevarlo hará que los escaneos de índice parezcan relativamente más costosos. Puedes elevar o bajar ambos valores juntos para cambiar la importancia de los costes de E/S de disco en relación con los costes de CPU, que se describen mediante los siguientes parámetros.

El acceso aleatorio al almacenamiento duradero suele ser mucho más costoso que cuatro veces el acceso secuencial. Sin embargo, se utiliza un valor predeterminado más bajo (4.0) porque se supone que la mayoría de los accesos aleatorios al almacenamiento, como las lecturas indexadas, se realizan en caché. Además, la latencia del almacenamiento conectado a la red tiende a reducir el gasto general relativo del acceso aleatorio.

Si crees que el almacenamiento en caché es menos frecuente de lo que refleja el valor predeterminado, y la latencia de la red es mínima, puedes aumentar random_page_cost para reflejar mejor el coste real de las lecturas aleatorias de almacenamiento. El almacenamiento que tiene un coste de lectura aleatoria más alto en relación con el secuencial, como los discos magnéticos, también podría modelarse mejor con un valor más alto para random_page_cost. Correspondientemente, si es probable que tus datos estén completamente en caché, como cuando la base de datos es más pequeña que la memoria total del servidor, o la latencia de la red es alta, disminuir random_page_cost podría ser apropiado.

Tip

Aunque el sistema te permitirá establecer random_page_cost en menos que seq_page_cost, no es físicamente sensato hacerlo. Sin embargo, establecerlos como iguales tiene sentido si la base de datos está completamente en caché en la RAM, ya que en ese caso no hay penalización por tocar páginas fuera de secuencia. Además, en una base de datos con un alto nivel de caché deberías bajar ambos valores en relación con los parámetros de la CPU, ya que el coste de recuperar una página que ya está en la RAM es mucho menor de lo que sería normalmente.

cpu_tuple_cost (floating point) #

Establece la estimación del planificador del coste de procesar cada fila durante una consulta. El valor predeterminado es 0.01.

cpu_index_tuple_cost (floating point) #

Establece la estimación del planificador del coste de procesar cada entrada de índice durante un escaneo de índice. El valor predeterminado es 0.005.

cpu_operator_cost (floating point) #

Establece la estimación del planificador del coste de procesar cada operador o función ejecutada durante una consulta. El valor predeterminado es 0.0025.

parallel_setup_cost (floating point) #

Establece la estimación del planificador del coste de lanzar procesos worker paralelos. El valor predeterminado es 1000.

parallel_tuple_cost (floating point) #

Establece la estimación del planificador del coste de transferir una tupla desde un proceso worker paralelo a otro proceso. El valor predeterminado es 0.1.

min_parallel_table_scan_size (integer) #

Establece la cantidad mínima de datos de tabla que se deben escanear para que se considere un escaneo paralelo. Para un escaneo secuencial paralelo, la cantidad de datos de tabla escaneados siempre es igual al tamaño de la tabla, pero cuando se utilizan índices la cantidad de datos de tabla escaneados normalmente será menor. If this value is specified without units, it is taken as blocks, that is BLCKSZ bytes, typically 8kB. El valor predeterminado es 8 megabytes (8MB).

min_parallel_index_scan_size (integer) #

Establece la cantidad mínima de datos de índice que se deben escanear para que se considere un escaneo paralelo. Ten en cuenta que un escaneo de índice paralelo normalmente no tocará todo el índice; es el número de páginas que el planificador cree que realmente serán tocadas por el escaneo lo que es relevante. Este parámetro también se utiliza para decidir si un índice en particular puede participar en un vacuum paralelo. Consulta la VACUUM. If this value is specified without units, it is taken as blocks, that is BLCKSZ bytes, typically 8kB. El valor predeterminado es 512 kilobytes (512kB).

effective_cache_size (integer) #

Establece la suposición del planificador sobre el tamaño efectivo de la caché de disco que está disponible para una sola consulta. Esto se factoriza en las estimaciones del coste de usar un índice; un valor más alto hace más probable que se utilicen escaneos de índice, un valor más bajo hace más probable que se utilicen escaneos secuenciales. Al establecer este parámetro debes considerar tanto los búferes compartidos de PostgreSQL como la porción de la caché de disco del kernel que se utilizará para los archivos de datos de PostgreSQL, aunque algunos datos puedan existir en ambos lugares. Además, ten en cuenta el número esperado de consultas concurrentes en diferentes tablas, ya que tendrán que compartir el espacio disponible. Este parámetro no tiene efecto en el tamaño de la memoria compartida asignada por PostgreSQL, ni reserva caché de disco del kernel; se utiliza únicamente con fines de estimación. El sistema tampoco asume que los datos permanezcan en la caché de disco entre consultas. Si este valor se especifica sin unidades, se toma como bloques, es decir, BLCKSZ bytes, normalmente 8kB. El valor predeterminado es 4 gigabytes (4GB). (Si BLCKSZ no es 8kB, el valor predeterminado se escala proporcionalmente a este).

jit_above_cost (floating point) #

Establece el coste de la consulta por encima del cual se activa la compilación JIT, si está habilitada (consulta la Chapter 30). Realizar JIT cuesta tiempo de planificación pero puede acelerar la ejecución de las consultas. Establecer esto en -1 deshabilita la compilación JIT. El valor predeterminado es 100000.

jit_inline_above_cost (floating point) #

Establece el coste de la consulta por encima del cual la compilación JIT intenta realizar la inserción en línea (inline) de funciones y operadores. La inserción en línea añade tiempo de planificación, pero puede mejorar la velocidad de ejecución. No tiene sentido establecer esto en menos que jit_above_cost. Establecer esto en -1 deshabilita la inserción en línea. El valor predeterminado es 500000.

jit_optimize_above_cost (floating point) #

Establece el coste de la consulta por encima del cual la compilación JIT aplica optimizaciones costosas. Dicha optimización añade tiempo de planificación, pero puede mejorar la velocidad de ejecución. No tiene sentido establecer esto en menos que jit_above_cost, y es poco probable que sea beneficioso establecerlo en más que jit_inline_above_cost. Establecer esto en -1 deshabilita las optimizaciones costosas. El valor predeterminado es 500000.

19.7.3. Optimizador genérico de consultas (Genetic Query Optimizer) #

El optimizador genérico de consultas (GEQO) es un algoritmo que realiza la planificación de consultas utilizando búsquedas heurísticas. Esto reduce el tiempo de planificación para consultas complejas (aquellas que unen muchas relaciones), a costa de producir planes que a veces son inferiores a los encontrados por el algoritmo normal de búsqueda exhaustiva. Para más información, consulta la Chapter 61.

geqo (boolean) #

Habilita o deshabilita la optimización genérica de consultas. Esto está activado por defecto. Por lo general, es mejor no desactivarlo en producción; la variable geqo_threshold proporciona un control más granular de GEQO.

geqo_threshold (integer) #

Utiliza la optimización genérica de consultas para planificar consultas con al menos este número de elementos en la cláusula FROM involucrados. (Ten en cuenta que una construcción FULL OUTER JOIN cuenta como un solo elemento FROM). El valor predeterminado es 12. Para consultas más simples, generalmente es mejor usar el planificador regular de búsqueda exhaustiva, pero para consultas con muchas tablas la búsqueda exhaustiva tarda demasiado tiempo, a menudo más que la penalización de ejecutar un plan subóptimo. Por lo tanto, un umbral en el tamaño de la consulta es una forma conveniente de gestionar el uso de GEQO.

geqo_effort (integer) #

Controla el compromiso entre el tiempo de planificación y la calidad del plan de consulta en GEQO. Esta variable debe ser un número entero en el rango de 1 a 10. El valor predeterminado es cinco. Los valores más grandes aumentan el tiempo dedicado a la planificación de consultas, pero también aumentan la probabilidad de que se elija un plan de consulta eficiente.

geqo_effort en realidad no hace nada directamente; solo se utiliza para calcular los valores predeterminados de las otras variables que influyen en el comportamiento de GEQO (descritas a continuación). Si lo prefieres, puedes configurar los otros parámetros a mano en su lugar.

geqo_pool_size (integer) #

Controla el tamaño del pool utilizado por GEQO, que es el número de individuos en la población genética. Debe ser al menos dos, y los valores útiles suelen ser de 100 a 1000. Si se establece en cero (la configuración predeterminada), entonces se elige un valor adecuado basado en geqo_effort y el número de tablas en la consulta.

geqo_generations (integer) #

Controla el número de generaciones utilizado por GEQO, que es el número de iteraciones del algoritmo. Debe ser al menos uno, y los valores útiles están en el mismo rango que el tamaño del pool. Si se establece en cero (la configuración predeterminada) entonces se elige un valor adecuado basado en geqo_pool_size.

geqo_selection_bias (floating point) #

Controla el sesgo de selección utilizado por GEQO. El sesgo de selección es la presión selectiva dentro de la población. Los valores pueden ser de 1.50 a 2.00; este último es el valor predeterminado.

geqo_seed (floating point) #

Controla el valor inicial del generador de números aleatorios utilizado por GEQO para seleccionar rutas aleatorias a través del espacio de búsqueda del orden de unión. El valor puede oscilar entre cero (el valor predeterminado) y uno. Variar el valor cambia el conjunto de rutas de unión exploradas y puede dar lugar a que se encuentre una mejor o peor ruta óptima.

19.7.4. Otras opciones del planificador #

default_statistics_target (integer) #

Establece el objetivo de estadísticas predeterminado para las columnas de tabla sin un objetivo específico de columna establecido mediante ALTER TABLE SET STATISTICS. Los valores más grandes aumentan el tiempo necesario para hacer ANALYZE, pero podrían mejorar la calidad de las estimaciones del planificador. El valor predeterminado es 100. Para obtener más información sobre el uso de estadísticas por parte del planificador de consultas de PostgreSQL, consulta la Section 14.2.

constraint_exclusion (enum) #

Controla el uso de restricciones de tabla por parte del planificador de consultas para optimizar las consultas. Los valores permitidos de constraint_exclusion son on (examinar las restricciones para todas las tablas), off (nunca examinar las restricciones) y partition (examinar las restricciones solo para las tablas hijes de herencia y subconsultas UNION ALL). partition es la configuración predeterminada. A menudo se utiliza con árboles de herencia tradicionales para mejorar el rendimiento.

Cuando este parámetro lo permite para una tabla en particular, el planificador compara las condiciones de la consulta con las restricciones CHECK de la tabla, y omite el escaneo de las tablas para las cuales las condiciones contradicen las restricciones. Por ejemplo:

CREATE TABLE parent(key integer, ...);
CREATE TABLE child1000(check (key between 1000 and 1999)) INHERITS(parent);
CREATE TABLE child2000(check (key between 2000 and 2999)) INHERITS(parent);
...
SELECT * FROM parent WHERE key = 2400;

Con la exclusión de restricciones habilitada, este SELECT no escaneará child1000 en absoluto, mejorando el rendimiento.

Actualmente, la exclusión de restricciones está habilitada por defecto solo para los casos que a menudo se utilizan para implementar la partición de tablas a través de árboles de herencia. Activarlo para todas las tablas impone un gasto de planificación adicional que es bastante notable en consultas simples, y la mayoría de las veces no producirá ningún beneficio para consultas simples. Si no tienes tablas particionadas utilizando la herencia tradicional, es posible que prefieras desactivarlo por completo. (Ten en cuenta que la característica equivalente para tablas particionadas está controlada por un parámetro independiente, enable_partition_pruning).

Consulta la Section 5.12.5 para obtener más información sobre el uso de la exclusión de restricciones para implementar particionado.

cursor_tuple_fraction (floating point) #

Establece la estimación del planificador de la fracción de las filas de un cursor que se recuperarán. El valor predeterminado es 0.1. Los valores más pequeños de esta configuración sesgan al planificador hacia el uso de planes de inicio rápido para los cursores, que recuperarán las primeras filas rápidamente mientras que tal vez tarden mucho tiempo en recuperar todas las filas. Los valores más grandes ponen más énfasis en el tiempo total estimado. En la configuración máxima de 1.0, los cursores se planifican exactamente como las consultas regulares, considerando solo el tiempo total estimado y no qué tan pronto se pueden entregar las primeras filas.

from_collapse_limit (integer) #

El planificador fusionará las subconsultas en consultas superiores si la lista FROM resultante no tiene más que este número de elementos. Los valores más pequeños reducen el tiempo de planificación pero podrían producir planes de consulta inferiores. El valor predeterminado es ocho. Para obtener más información, consulta la Section 14.3.

Establecer este valor en geqo_threshold o más puede activar el uso del planificador GEQO, lo que resulta en planes no óptimos. Consulta la Section 19.7.3.

jit (boolean) #

Determina si PostgreSQL puede utilizar la compilación JIT, si está disponible (consulta la Chapter 30). El valor predeterminado es on.

join_collapse_limit (integer) #

El planificador reescribirá construcciones JOIN explícitas (excepto los FULL JOINs) en listas de elementos FROM siempre que resulte una lista de no más de esta cantidad de elementos. Los valores más pequeños reducen el tiempo de planificación pero podrían producir planes de consulta inferiores.

Por defecto, esta variable se establece igual que from_collapse_limit, lo cual es adecuado para la mayoría de los usos. Establecerlo en 1 evita cualquier reordenación de los JOINs explícitos. Por lo tanto, el orden de unión explícito especificado en la consulta será el orden real en el que se unen las relaciones. Debido a que el planificador de consultas no siempre elige el orden de unión óptimo, los usuarios avanzados pueden optar por establecer temporalmente esta variable en 1, y luego especificar el orden de unión que desean explícitamente. Para obtener más información, consulta la Section 14.3.

Establecer este valor en geqo_threshold o más puede activar el uso del planificador GEQO, lo que resulta en planes no óptimos. Consulta la Section 19.7.3.

plan_cache_mode (enum) #

Las sentencias preparadas (ya sean explícitamente preparadas o generadas implícitamente, por ejemplo por PL/pgSQL) se pueden ejecutar utilizando planes personalizados o genéricos. Los planes personalizados se crean de nuevo para cada ejecución utilizando su conjunto específico de valores de parámetros, mientras que los planes genéricos no dependen de los valores de los parámetros y se pueden reutilizar entre ejecuciones. Por lo tanto, el uso de un plan genérico ahorra tiempo de planificación, pero si el plan ideal depende en gran medida de los valores de los parámetros, un plan genérico puede ser ineficiente. La elección entre estas opciones normalmente se realiza de forma automática, pero se puede invalidar con plan_cache_mode. Los valores permitidos son auto (el valor predeterminado), force_custom_plan y force_generic_plan. Esta configuración se considera cuando se va a ejecutar un plan almacenado en caché, not cuando se prepara. For more information see PREPARE.

recursive_worktable_factor (floating point) #

Establece la estimación del planificador del tamaño promedio de la tabla de trabajo (worktable) de una consulta recursiva, como un múltiplo del tamaño estimado del término no recursivo inicial de la consulta. Esto ayuda al planificador a elegir el método más apropiado para unir la tabla de trabajo con las otras tablas de la consulta. El valor predeterminado es 10.0. Un valor más pequeño como 1.0 puede ser útil cuando la recursión tiene un bajo factor de ramificación (fan-out) de un paso al siguiente, como por ejemplo en consultas de ruta más corta. Las consultas analíticas de grafos pueden beneficiarse de valores mayores que el predeterminado.