Hologres:ANALYZE and AUTO ANALYZE

¿Por qué son necesarias las estadísticas?

El optimizador depende de las estadísticas de tablas y columnas para generar planes de ejecución adecuados, entre las que se incluyen:

• Recuento de filas y recuento de columnas

• Ancho de columna (Width)

• Número de valores distintos (NDV)

• Valores más comunes (MCV) y sus frecuencias

• Histograma y otras características de distribución

Esta información guía al optimizador para:

• Estimar el costo de ejecución del operador

• Reducir el espacio de búsqueda del plan de ejecución

• Seleccionar el orden de Join y los algoritmos de Join apropiados

• Estimar la memoria y el paralelismo

Esto da como resultado un plan de ejecución más óptimo.

El comando ANALYZE es el método estándar para que los usuarios recopilen activamente estadísticas de tablas y columnas. Cuando faltan estadísticas o son inexactas, el plan de consulta puede degradarse significativamente; por ejemplo, un orden de Join anómalo que se manifiesta como: OOM en la consulta, tiempo de ejecución prolongado o alto consumo de CPU de la instancia.

AUTO ANALYZE es el método estándar para que el sistema Hologres recopile automáticamente estadísticas de tablas y columnas. Dado que AUTO ANALYZE es un comportamiento asíncrono del sistema en segundo plano, existe un retraso de decenas de segundos a minutos desde que cambian los datos de la tabla hasta que AUTO ANALYZE detecta, programa y completa la recopilación automática de estadísticas. Por lo tanto, en algunos escenarios específicos, se recomienda que los usuarios ejecuten manualmente ANALYZE para asegurar que las estadísticas se recopilen de manera oportuna.

Cuándo ejecutar manualmente ANALYZE

Se recomienda la ejecución manual en los siguientes escenarios:

• Después de operaciones INSERT / UPDATE / DELETE que importen, actualicen o eliminen una gran cantidad de datos en una tabla, y dicha tabla se consultará inmediatamente, se recomienda ejecutar ANALYZE en la tabla después del INSERT / UPDATE / DELETE;

• Cuando el rendimiento de Join de múltiples tablas se degrada significativamente, ejecute ANALYZE a nivel de columna en las columnas clave de Join y en las columnas de Group By;

• Después de ejecutar CREATE FOREIGN TABLE o IMPORT FOREIGN SCHEMA para una tabla externa, y esta se consultará inmediatamente, se recomienda ejecutar ANALYZE en la tabla externa recién creada antes de consultarla para recopilar estadísticas iniciales;

• Después de ejecutar CREATE EXTERNAL DATABASE, y esta se consultará inmediatamente, se recomienda ejecutar ANALYZE en las tablas que necesiten ser consultadas dentro de la base de datos externa antes de realizar la consulta;

• Cuando ocurre uno de los siguientes errores o síntomas:

  • Error de OOM en Join de múltiples tablas: Query executor exceeded total memory limitation ..., o Query exceed per query memory limitation ...;

  • Error en Join de múltiples tablas: Capacity error: BinaryArray cannot contain more than 2147483646 bytes ...;

  • Las tareas de importación o consulta se ejecutan durante un tiempo anormalmente largo con una utilización desigual de la CPU.

  • EXPLAIN <SQL> muestra un operador Scan con un recuento estimado de filas de 1000, -> Seq Scan on tbl (cost=0.00..5.00 rows=1000 width=1); esto indica que la tabla carece de estadísticas.

  • EXPLAIN <SQL> muestra un operador Scan con un recuento estimado de filas de 1, -> Seq Scan on tbl (cost=0.00..1.00 rows=1 width=1); esto indica que se estima que la tabla tiene 0 filas. Si el resultado real del Scan no es 0 filas, es posible que las estadísticas estén desactualizadas y se recomienda un ANALYZE manual.

En los escenarios anteriores, generalmente se recomienda primero ejecutar manualmente ANALYZE y observar si el rendimiento se recupera, para luego ajustar adicionalmente la configuración de AUTO ANALYZE.

Sintaxis básica y comportamiento

• Recopilar estadísticas para todas las columnas de toda la tabla

ANALYZE table_name;

• Recopila el recuento de filas de la tabla y recopila uniformemente Width, MCV, Histogram, NDV y otras estadísticas para todas las columnas regulares de la tabla;

• Utiliza un enfoque basado en muestreo para estimar varios valores estadísticos. La operación de muestreo inicia una subconsulta SQL de muestreo dentro del proceso de ANALYZE.

• De forma predeterminada, ANALYZE toma una muestra aleatoria de 30,000 filas de la tabla para la recopilación y el cálculo de estadísticas. Si la tabla tiene menos de 30,000 filas, se toman como muestra todas las filas.

• Recopilar estadísticas solo para columnas específicas (recomendado para columnas clave)

ANALYZE table_name(col1, col2, ...);

• Calcula un NDV más preciso para las columnas especificadas (generalmente usando la lógica de APPROX_COUNT_DISTINCT), lo cual es más preciso que el muestreo a nivel de tabla pero más costoso;

• MCV, Histogram, Width y otras estadísticas todavía se obtienen mediante muestreo;

• Cuando se ejecuta ANALYZE varias veces en la misma columna, la ejecución posterior sobrescribe las estadísticas antiguas de esa columna, pero no afecta a otras columnas no especificadas.

Limitaciones y consideraciones

• Qué columnas no se analizarán

  • Tipos no compatibles: Cuando el tipo de una columna es un tipo definido por el usuario o no está en el conjunto de tipos que Hologres admite para estadísticas, se omitirá la recopilación de estadísticas:

    • Los tipos de columna que no admiten ANALYZE incluyen: "char" (tipo de carácter único), BIT, VARBIT, BYTEA, NAME, JSON, TSVECTOR, TSQUERY, OID, XID, CID, INET, POINT, LINE, LSEG, BOX, CIRCLE, PATH, POLYGON, BITARRAY, VARBITARRAY, BYTEAARRAY, INT2ARRAY, MONEYARRAY, NUMERICARRAY, TIMEARRAY, TIMETZARRAY, TIMESTAMPTZARRAY, TIMESTAMPARRAY, ANYARRAY, REGCLASS, DATEARRAY u otros tipos INTERNAL.

    • Cuando el tipo de columna no es compatible, tanto el ANALYZE manual como AUTO ANALYZE se ignorarán;

    • Para tablas particionadas, los tipos de columna que no admiten la fusión incremental de estadísticas de partición tampoco se analizarán. Además de los tipos enumerados anteriormente, los tipos no compatibles también incluyen: BOOLARRAY, INT4ARRAY, TEXTARRAY, BPCHARARRAY, VARCHARARRAY, INT8ARRAY, FLOAT4ARRAY, FLOAT8ARRAY.

  • Columnas marcadas como eliminadas: Las columnas lógicas retenidas después de ALTER TABLE ... DROP COLUMN (attisdropped = true) no se analizarán;

  • Deshabilitado explícitamente por atributo de columna:

    • Las columnas con el atributo de columna enable_analyze = false no serán procesadas por ANALYZE ni por AUTO ANALYZE;

    • Las columnas con el atributo de columna enable_auto_analyze = false no serán procesadas por AUTO ANALYZE.

    • Para obtener detalles sobre estos atributos de columna, consulte las secciones posteriores.

  • Estadísticas de columna JSONB no habilitadas:

    • Si el tipo de columna es JSONB y enable_jsonb_stats no está habilitado, no se recopilarán estadísticas JSONB para esa columna;

    • Si necesita depender de estadísticas de columna JSONB (por ejemplo, condiciones de filtro JSON complejas), primero debe habilitar enable_jsonb_stats en los atributos de la columna.

• Limitaciones de ANALYZE para tablas de data lake

  • No se admite ANALYZE para Timestamp, Version, Branch, Snapshot o Tag específicos de forma individual

Uso típico

• Uso típico recomendado

  • Ejecute ANALYZE a nivel de columna en columnas de Join, columnas de Group By y columnas de condición de filtro:

ANALYZE tablename (order_id, user_id, dt);

• • Después de una importación o actualización por lotes, ejecute en las tablas que se vean significativamente afectadas:

ANALYZE tablename;

• • Ejecute en tablas externas (FOREIGN TABLE / IMPORT FOREIGN SCHEMA / tablas bajo EXTERNAL DATABASE) antes de la primera consulta:

ANALYZE foreign_table;

• Omitir la recopilación de estadísticas para columnas específicas estableciendo atributos de columna

  • Hologres permite controlar si se ejecuta ANALYZE o AUTO ANALYZE en una columna mediante atributos a nivel de columna, lo cual es aplicable a los siguientes escenarios:

    • Las columnas ultra anchas (como Text muy largos) tienen un alto costo de recopilación de estadísticas, y recopilar estadísticas para ellas proporciona un beneficio limitado o nulo al plan de consulta;

    • Ciertas columnas nunca participan en Joins, filtrados o agregaciones, y no necesitan recopilación de estadísticas;

    • Necesidad de reducir el consumo de recursos de ANALYZE o AUTO ANALYZE.

  • Los parámetros de control son las siguientes opciones de columna:

    • enable_analyze: Controla si la columna participa en el ANALYZE manual y en el AUTO ANALYZE automático. El valor predeterminado es true;

    • enable_auto_analyze: Controla únicamente si la columna participa en el AUTO ANALYZE automático. El valor predeterminado es true.

  • Método de configuración (mediante el comando ALTER TABLE):

-- Disable ANALYZE and AUTO ANALYZE for a specific column
ALTER TABLE t ALTER COLUMN bitmap_col SET (enable_analyze = false);

-- Disable AUTO ANALYZE for a specific column while still allowing manual ANALYZE
ALTER TABLE t ALTER COLUMN large_text_col SET (enable_auto_analyze = false);

-- Restore default behavior (re-enable)
ALTER TABLE t ALTER COLUMN bitmap_col RESET (enable_analyze);
ALTER TABLE t ALTER COLUMN large_text_col RESET (enable_auto_analyze);

• • Consideraciones:

    • Después de establecer enable_analyze = false, la columna se omitirá automáticamente al ejecutar ANALYZE table_name;, pero aún se puede recopilar explícitamente mediante ANALYZE table_name(col); manual;

    • Después de establecer enable_auto_analyze = false, la columna no será recopilada por AUTO ANALYZE, pero aún se puede recopilar explícitamente mediante ANALYZE table_name(col); manual;

    • Si una columna tiene un impacto significativo en el plan de consulta (como columnas de Join o columnas de condición de filtro), no se recomienda deshabilitar su recopilación de estadísticas.

Escenarios y limitaciones

• En Hologres V2.0 y versiones posteriores, el ANALYZE incremental de particiones está habilitado de forma predeterminada sin necesidad de configuración manual. Para más detalles, consulte las notas de la versión del producto;

• Cuando está habilitado, ejecutar ANALYZE en una partición hija intentará combinar sus estadísticas con las de otras particiones hijas para producir las estadísticas de la tabla padre;

• El requisito previo para fusionar las estadísticas de la tabla padre es que, aparte de la partición hija que se está analizando actualmente, todas las demás particiones hijas bajo la tabla padre ya deben tener estadísticas (incluyendo estadísticas de recuento de filas y estadísticas de columnas);

• Por lo tanto, usted puede:

  • Durante la configuración inicial, ejecute primero ANALYZE en la tabla padre. El sistema detectará automáticamente las particiones hijas que necesitan ANALYZE y las analizará una por una, fusionando finalmente los resultados en las estadísticas de la tabla padre;

  • Cuando se agreguen nuevas particiones posteriormente, solo necesitará ejecutar ANALYZE en las particiones hijas recién agregadas.

Ejemplo breve

BEGIN;
DROP TABLE IF EXISTS t_parent;
CREATE TABLE t_parent(a int, b int) PARTITION BY LIST (a);
CREATE TABLE child1 PARTITION OF t_parent FOR VALUES IN (1);
CREATE TABLE child2 PARTITION OF t_parent FOR VALUES IN (2);
COMMIT;
insert into child1 values (1, 1), (1, 1), (1, 1), (1, 1), (1, 1), (1, 1), (1, 1), (1, 1), (1, 1), (1, 2);
insert into child2 values (2, 1), (2, 2), (2, 3), (2, 4), (2, 5), (2, 5), (2, 5), (2, 5), (2, 5), (2, 5);

-- child2 lacks statistics, so parent table statistics cannot be merged
dbname=# ANALYZE child1;
INFO:  auto merging of leaf partition stats to calculate root partition stats is not possible because partition child2 is not analyzed
ANALYZE

-- child1 already has statistics. After analyzing child2, parent table statistics can be automatically merged
dbname=# ANALYZE child2;
ANALYZE

dbname=# SELECT tablename,
       attname,
       null_frac         AS "NF",
       avg_width,
       n_distinct,
       most_common_vals  AS "MCV",
       most_common_freqs AS "MCV_FRAQ"
FROM   pg_stats
WHERE  tablename = 't_parent';

 tablename | attname | NF | avg_width | n_distinct |  MCV  |  MCV_FRAQ
-----------+---------+----+-----------+------------+-------+------------
 t_parent  | a       |  0 |         4 |          2 | {1,2} | {0.5,0.5}
 t_parent  | b       |  0 |         4 |       -0.2 | {1,5} | {0.45,0.3}
(2 rows)

-- After this, when new partitions are added, you only need to ANALYZE the child partition. Parent table statistics will be automatically merged through sampling the child partition only.

ANALYZE en la tabla padre

A veces, varias particiones hijas de una tabla particionada han sufrido cambios en los datos y no desea ejecutar ANALYZE en cada partición hija individualmente. En este caso, puede realizar un único ANALYZE en la tabla padre.

Cuando el ANALYZE incremental de particiones está habilitado, ejecutar manualmente ANALYZE en la tabla padre hace que el sistema seleccione adaptativamente las particiones hijas que necesitan actualizaciones de estadísticas, en lugar de analizar ciegamente todas las particiones hijas. Este mecanismo reduce significativamente el costo de ANALYZE para tablas particionadas grandes, garantizando al mismo tiempo la precisión de las estadísticas.

-- Execute ANALYZE on the parent table
ANALYZE partition_parent_table;

INFO:  will analyze 5 part tables first (stats changed 3, unable-to-merge 2)

ANALYZE para tablas particionadas lógicas

Una tabla particionada lógica es un tipo de tabla de partición exclusivo de Hologres. A diferencia de las tablas particionadas estándar de PostgreSQL (que crean tablas hijas físicas mediante PARTITION BY), una tabla particionada lógica permanece físicamente como una sola tabla y solo particiona los datos lógicamente según los valores de la columna de partición, proporcionando capacidades de gestión de particiones más flexibles.

La lógica de ANALYZE para tablas particionadas lógicas es esencialmente la misma que para las tablas particionadas físicas. La única diferencia es que las particiones hijas de una tabla particionada lógica no son tablas separadas, pero al igual que las particiones hijas físicas, cada una todavía tiene sus propias estadísticas de recuento de filas y estadísticas de columnas independientes.

-- Create a logical partitioned table
CREATE TABLE user_events (
    user_id INT NOT NULL,
    event_type TEXT NOT NULL,
    event_date DATE NOT NULL,
    event_data INT
)
LOGICAL PARTITION BY LIST(user_id, event_date);

-- Insert data into different logical partitions
INSERT INTO user_events SELECT 1, 'login', '2024-11-01', i FROM generate_series(1, 1000) i;
INSERT INTO user_events SELECT 1, 'logout', '2024-11-02', i FROM generate_series(1, 1000) i;
INSERT INTO user_events SELECT 2, 'purchase', '2024-11-03', i FROM generate_series(1, 1000) i;
INSERT INTO user_events SELECT 3, 'view', '2024-11-04', i FROM generate_series(1, 1000) i;

-- Execute ANALYZE on the parent table
ANALYZE VERBOSE user_events;

INFO:  will analyze 4 logical partitions first
INFO:  analyzing hologres table "public.user_events" PARTITION (user_id=1,event_date='2024-11-01')
INFO:  analyzing hologres table "public.user_events" PARTITION (user_id=1,event_date='2024-11-02')
INFO:  analyzing hologres table "public.user_events" PARTITION (user_id=2,event_date='2024-11-03')
INFO:  analyzing hologres table "public.user_events" PARTITION (user_id=3,event_date='2024-11-04')
INFO:  try to merge root partition
INFO:  automatically merging leaf partition stats to calculate root partition stats

-- Execute ANALYZE on a single logical partition
ANALYZE user_events PARTITION (user_id=1, event_date='2024-11-01');

-- Execute ANALYZE on multiple logical partitions
ANALYZE user_events
    PARTITION (user_id=1, event_date='2024-11-01')
    PARTITION (user_id=2, event_date='2024-11-03');

-- Execute ANALYZE on specific columns of a specified logical partition
ANALYZE user_events
    PARTITION (user_id=1, event_date='2024-11-01') (user_id, event_type);

SELECT
    unique_name,
    schema_name,
    table_name,
    total_rows,
    sample_rows,
    nattr
FROM hologres_statistic.hg_table_statistic
WHERE table_name = 'user_events'
ORDER BY unique_name;

| unique_name | schema_name | table_name | total_rows | sample_rows | nattr |
|-------------|-------------|------------|------------|-------------| ----- |
| user_events | public | user_events | 4000 | 0 | 4 |
| user_events.a1b2c3d4e5f6... | public | user_events | 1000 | 1000 | 4 |
| user_events.f6e5d4c3b2a1... | public | user_events | 1000 | 1000 | 4 |
| user_events.1234567890ab... | public | user_events | 1000 | 1000 | 4 |
| user_events.abcdef123456... | public | user_events | 1000 | 1000 | 4 |

Interruptor y alcance

-- Check whether AUTO ANALYZE is enabled for the current database
SHOW hg_enable_start_auto_analyze_worker;

-- Disable (use only for temporary troubleshooting)
ALTER DATABASE dbname SET hg_enable_start_auto_analyze_worker = OFF;

-- Reset to the default value ON (recommended)
ALTER DATABASE dbname RESET hg_enable_start_auto_analyze_worker;

ALTER TABLE my_table SET (autovacuum_enabled = false);

-- Recommended: reset to restore the default
ALTER TABLE my_table RESET (autovacuum_enabled);

-- Or explicitly set to true (not recommended)
ALTER TABLE my_table SET (autovacuum_enabled = true);

SELECT relname, reloptions FROM pg_class WHERE relname = 'my_table';

 relname  |         reloptions
----------+----------------------------
 my_table | {autovacuum_enabled=false}
(1 row)

-- Disable AUTO ANALYZE for a specific column while still allowing manual ANALYZE
ALTER TABLE t ALTER COLUMN large_text_col SET (enable_auto_analyze = false);

-- Restore default behavior (re-enable)
ALTER TABLE t ALTER COLUMN large_text_col RESET (enable_auto_analyze);

Lógica de activación de AUTO ANALYZE

AUTO ANALYZE combina varios tipos de señales para determinar si es necesario actualizar las estadísticas de una tabla específica:

1. Volumen de cambios en los datos

   • Aplica únicamente a tablas regulares de Hologres (excluye tablas externas);

   • A intervalos de 1 minuto, recopila el conteo de filas de las operaciones INSERT/UPDATE/DELETE observadas por el FE en cada tabla. Si el cambio supera el umbral, se activa un AUTO ANALYZE (respuesta rápida);

   • A intervalos de 10 minutos, obtiene los conteos de filas modificadas por inserción, actualización o eliminación desde el motor de almacenamiento. Si el cambio supera el umbral, se activa un AUTO ANALYZE (calibración precisa);

2. Cambios en el esquema

   • Aplica únicamente a tablas regulares de Hologres (excluye tablas externas);

   • A intervalos de 1 minuto, recopila las tablas con los siguientes cambios y ejecuta AUTO ANALYZE:

     • ADD / DROP COLUMN;

     • Tablas particionadas (incluidas las tablas de particiones lógicas) ATTACH / DETACH child partitions.

3. Estadísticas faltantes / Imposibilidad de fusionar estadísticas de la tabla padre de particiones

   • Aplica tanto a tablas regulares de Hologres como a tablas externas;

   • A intervalos de 1 minuto, recopila tablas o columnas con estadísticas faltantes y particiones secundarias que no cumplen las condiciones para la fusión incremental de estadísticas.

4. Tablas externas

   • Aplica únicamente a tablas externas introducidas mediante CREATE FOREIGN TABLE, IMPORT FOREIGN SCHEMA o el mecanismo Auto Load en contextos que no son External Database;

   • Actualmente solo admite AUTO ANALYZE para tablas externas de MaxCompute;

   • A intervalos de 4 horas, comprueba periódicamente todas las tablas externas en la base de datos. Si entre dos comprobaciones hay cambios en los datos externos (el criterio es que el last_modify_timestamp de la tabla externa correspondiente caiga entre los dos intervalos de comprobación), se activa un AUTO ANALYZE.

5. Estadísticas de respaldo

   • Durante la ventana de 1:00 a 5:00 AM, se realiza un AUTO ANALYZE de "respaldo" en tablas que tienen cambios continuos pero no han alcanzado el umbral (>5000 filas modificadas, <10% de volumen de cambio), para capturar desviaciones en la distribución de datos de las columnas (por ejemplo, campos de tipo fecha escritos después de la medianoche del día siguiente son completamente diferentes a los del día anterior, lo que provoca cambios en la distribución).

6. Tablas con alta frecuencia de acceso (solo External Database)

   • Tras habilitar el parámetro enable_auto_analyze en una External Database, el sistema Hologres comienza a rastrear las tablas accedidas recientemente desde el último inicio del sistema y las agrega a la lista de observación;

   • A intervalos de 1 hora, las tablas en la lista de observación que tienen "acceso frecuente reciente" activan un AUTO ANALYZE;

   • Tenga en cuenta que, tras reiniciar el sistema, la lista de tablas accedidas se borra y el registro comienza de nuevo.

AUTO ANALYZE para External Database

• A partir de Hologres V3.0, Hologres admite la función External Database. Al crear una External Database, puede habilitar AUTO ANALYZE (deshabilitado de forma predeterminada; consulte las notas de la versión para más detalles):

-- Enable AUTO ANALYZE when creating an External Database
-- Reference: https://www.alibabacloud.com/help/zh/hologres/developer-reference/create-external-database
CREATE EXTERNAL DATABASE <ext_database_name> WITH
  metastore_type 'maxcompute'
  mc_project 'project_name'
  enable_auto_analyze 'true';

-- Enable AUTO ANALYZE for an existing External Database
ALTER EXTERNAL DATABASE dbname WITH enable_auto_analyze 'true';

• El alcance de metastore_type admitido por AUTO ANALYZE en External Database es: dlf, dlf-paimon, dlf-rest, maxcompute.

• Los formatos de tabla admitidos por AUTO ANALYZE en External Database incluyen: MaxCompute, Paimon, Iceberg.

• AUTO ANALYZE en External Database utiliza la identidad del propietario de la External Database de forma predeterminada y emplea autenticación mediante contraseña de un solo uso basada en tiempo (TOTP) para ejecutar tareas de ANALYZE. Si el propietario no tiene permisos suficientes sobre la tabla, el sistema no podrá ejecutar correctamente las tareas de AUTO ANALYZE.

• Para que una tabla externa en una External Database sea elegible para AUTO ANALYZE, se deben cumplir las siguientes condiciones:

  • La configuración de la External Database hg_enable_start_auto_analyze_worker = on; (activado de forma predeterminada)

  • El atributo de la External Database enable_auto_analyze está establecido en true (no configurado de forma predeterminada, lo que equivale a false; consulte las notas de la versión para más detalles)

  • El propietario de la External Database debe tener permisos de consulta sobre el proyecto de data lake (si aplica) y sobre la tabla

  • Se debe haber accedido a la tabla al menos una vez en los últimos 3 días

    • AUTO ANALYZE en External Database solo monitorea tablas externas a las que se ha accedido al menos una vez;

    • Tras reiniciar el sistema, si se accede a una tabla externa al menos una vez, el sistema AUTO ANALYZE la agrega a la lista de observación y activa periódicamente AUTO ANALYZE para dichas tablas;

Límites de recursos de AUTO ANALYZE

Para evitar que las tareas de AUTO ANALYZE en segundo plano afecten las tareas de usuario en primer plano, Hologres ha establecido los siguientes límites de recursos para la función AUTO ANALYZE:

• Cuando se ejecutan tareas de AUTO ANALYZE, el límite de memoria predeterminado por worker es de 4 GB. Si el volumen de datos de la tabla es demasiado grande, el muestreo puede exceder el límite de memoria, lo que provoca errores en el SQL de muestreo de AUTO ANALYZE. En tales casos, solo se puede recopilar información del conteo de filas, pero no la información de distribución de columnas (MCV, Histograma, NDV, etc.). Puede ajustar auto_analyze_work_memory_mb para modificar este comportamiento. Cuanto mayor sea la especificación de la instancia, mayor será el límite de memoria disponible para AUTO ANALYZE.

• La concurrencia a nivel de instancia para tareas de AUTO ANALYZE programadas simultáneamente normalmente no excede 4, y en casos extremos no excede 6.

• Para tareas de AUTO ANALYZE de particiones secundarias bajo la misma tabla particionada, la concurrencia máxima de programación simultánea es 3.

• De forma predeterminada, AUTO ANALYZE recopila estadísticas para las primeras 256 columnas. Si una tabla tiene más de 256 columnas, solo se recopilan las primeras 256 (en tablas particionadas, las columnas de partición tienen prioridad y se recopilan incluso si están más allá de la posición 256). Puede ajustar hg_experimental_auto_analyze_max_columns_count para cambiar este valor.

• Las subconsultas SQL de muestreo de las tareas de AUTO ANALYZE se ejecutan utilizando un Background Pool de baja prioridad con concurrencia limitada a nivel de ejecución de consultas. Esto hace que las tareas de AUTO ANALYZE tarden más que un ANALYZE manual, algo que no debe preocupar a los usuarios.

• Para tablas externas, AUTO ANALYZE solo recopila estadísticas de columna para las columnas de partición (por ejemplo, MCV). No realiza muestreo para recopilar estadísticas de columnas distintas a las de partición.

Parámetros configurables de AUTO ANALYZE

De forma predeterminada, la función AUTO ANALYZE de Hologres no requiere ninguna modificación de parámetros.

En escenarios empresariales poco frecuentes (como escrituras o actualizaciones de datos infrecuentes, cargas de trabajo de consulta que no necesitan estadísticas o aumentos en la carga del sistema causados por AUTO ANALYZE), los usuarios pueden modificar ciertos parámetros predeterminados para ajustar el comportamiento de AUTO ANALYZE con fines de intervención o ajuste parcial del rendimiento.

-- Superuser: modify the default AUTO ANALYZE parameters at the database level
ALTER DATABASE dbname SET <GUC> = <values>;

Interruptor

Cómo habilitar la estimación rápida de conteo de filas:

-- Disable (use only for temporary troubleshooting or when statistics are not needed for the entire database)
ALTER DATABASE dbname SET hg_experimental_get_fast_num_of_rows = OFF;

-- V3.2 and later: enable (reset to the default value)
ALTER DATABASE dbname RESET hg_experimental_get_fast_num_of_rows;

-- V3.1 and earlier: enable
ALTER DATABASE dbname SET hg_experimental_get_fast_num_of_rows = ON;

Límites de uso

• La estimación rápida de conteo de filas aplica a tablas regulares (incluidas tablas particionadas), tablas externas en External Database y otros escenarios.

• No se garantiza que el conteo de filas estimado por la función de estimación rápida sea completamente preciso. Por ejemplo, por motivos de rendimiento, en tablas particionadas de Hologres solo se utilizan las estadísticas de conteo de filas de hasta 60 particiones (de forma predeterminada) para estimar el conteo total de filas de la tabla particionada.

• En V4.1.15 y versiones anteriores, la estimación rápida de conteo de filas no está habilitada de forma predeterminada para tipos de tabla externa (Foreign Table). Se puede habilitar mediante el parámetro hg_experimental_enable_foreign_table_get_fast_num_of_rows. Está habilitada de forma predeterminada en V4.1.16 y versiones posteriores.

• Para tipos de tabla externa, la estimación rápida de conteo de filas solo admite tablas externas de MaxCompute, tablas externas de Paimon y tablas externas de Iceberg.

Ejemplos

1. Ejemplo de hg_experimental_get_fast_num_of_rows

Si una tabla no tiene estadísticas, habilitar la estimación rápida de conteo de filas puede proporcionar conteos más precisos. (Habilitado de forma predeterminada en Hologres V3.2 y posteriores)

-- V3.2+
create table test_tbl (a int);
insert into test_tbl select * from generate_series (1, 999);

-- Accurate row count estimation (rows=999)
explain select count(1) from test_tbl ;
                                       QUERY PLAN
----------------------------------------------------------------------------------------
 Final Aggregate  (cost=0.00..5.00 rows=1 width=8)
   ->  Gather  (cost=0.00..5.00 rows=10 width=8)
         ->  Partial Aggregate  (cost=0.00..5.00 rows=10 width=8)
               ->  Local Gather  (cost=0.00..5.00 rows=20 width=8)
                     ->  Partial Aggregate  (cost=0.00..5.00 rows=20 width=8)
                           ->  Seq Scan on test_tbl  (cost=0.00..5.00 rows=999 width=1)

A continuación se presenta un caso real de producción:

Sin esta función habilitada, si una tabla no tiene estadísticas, el nodo Scan en el plan de consulta mostrará rows=1000 (lo que indica que no hay estadísticas disponibles y el plan se genera basándose en la estimación predeterminada de 1000 filas).

Tras habilitar esta función, si una tabla no tiene estadísticas, el valor de filas del nodo Scan en el plan de consulta no será igual a 1000 (el sistema consultó los metadatos del motor de almacenamiento subyacente para obtener el conteo de filas de la tabla).

Parámetros configurables para la estimación rápida de conteo de filas

Cómo identificar registros de ANALYZE y AUTO ANALYZE en el query log

ANALYZE y AUTO ANALYZE, junto con sus sentencias SQL de muestreo, se registran por separado en el Query Log.

Los registros de ejecución tienen las siguientes características en el Query Log:

ANALYZE y su SQL de muestreo se asocian a través de los comentarios en el campo query, o mediante extended_info->>'source_query_id'.

SELECT query_id,
       extended_info->>'src_query_id' as "source query id",
       application_name,
       status,
       duration
FROM   hologres.hg_query_log
WHERE  query_start >= now() - interval '1 hour'
  AND  application_name IN ('AutoAnalyze', 'Hologres SQL Generated BY AUTO ANALYZE')
ORDER BY query_start DESC
LIMIT  2;
      query_id       |   source query id   |            application_name            | status  | duration
---------------------+---------------------+----------------------------------------+---------+----------
 1004019226350863009 | 1004019226350778807 | Hologres SQL Generated BY AUTO ANALYZE | SUCCESS |      119
 1004019226350778807 |                     | AutoAnalyze                            | SUCCESS |     3276

Ejemplos de consultas

• Consultar registros recientes de ejecución de AUTO ANALYZE

SELECT usename,
       status,
       duration,
       query_start,
       query_end,
       query,
       application_name
FROM   hologres.hg_query_log
WHERE  query_start >= now() - interval '1 hour'
  AND  application_name IN ('AutoAnalyze')
ORDER BY query_start DESC
LIMIT  20;

       query_id,
       extended_info->>'src_query_id' as "source query id"

• Consultar el historial de ejecución de AUTO ANALYZE de una tabla específica

SELECT status,
       duration,
       query_start,
       query
FROM   hologres.hg_query_log
WHERE  query_start >= now() - interval '1 day'
  AND  application_name IN ('AutoAnalyze')
  AND  query LIKE '%my_table_name%'
ORDER BY query_start DESC;

• Resumir la visión general de ejecuciones de AUTO ANALYZE de los últimos 3 días

SELECT query_date,
       status,
       COUNT(*)          AS task_count,
       AVG(duration)     AS avg_duration_ms,
       MAX(duration)     AS max_duration_ms
FROM   hologres.hg_query_log
WHERE  query_start >= CURRENT_DATE::timestamptz - interval '2 day'
  AND  application_name IN ('AutoAnalyze')
  AND  command_tag = 'ANALYZE'
  AND  (status = 'SUCCESS' OR (
            message NOT LIKE '%does not exist%'
        AND message NOT LIKE '%retry later%'))
GROUP BY query_date, status
ORDER BY query_date DESC;

• Consultar tareas de AUTO ANALYZE con errores en el último día

SELECT query_start,
       duration,
       message,
       query
FROM   hologres.hg_query_log
WHERE  query_start >= now() - interval '1 day'
  AND  application_name IN ('AutoAnalyze', 'Hologres SQL Generated BY AUTO ANALYZE')
  AND  status != 'SUCCESS'
  AND  (message NOT LIKE '%does not exist%'
        AND message NOT LIKE '%retry later%')
ORDER BY query_start DESC;

Notas

• Dado que las conexiones de AUTO ANALYZE se inician con una identidad de administrador interno, los usuarios regulares necesitan el rol pg_read_all_stats o privilegios de administrador de base de datos para consultar registros completos de ejecución de AUTO ANALYZE.

• Si nota que no hay registros de AUTO ANALYZE en el Query Log durante un período prolongado, se recomienda comprobar si el interruptor de AUTO ANALYZE está habilitado.

Consulta de estadísticas de tablas (hologres_statistic.hg_table_statistic)

Las estadísticas de las tablas se almacenan en la tabla hologres_statistic.hg_table_statistic y también se pueden observar en las tablas del sistema.

1. Consulte esta tabla para obtener las estadísticas del ANALYZE más reciente.

SELECT schema_name,                -- Table schema
       table_name,                 -- Table name
       user_name,                  -- User who last ran ANALYZE
       schema_version,             -- Table schema version at last ANALYZE
       total_rows,                 -- Row count at last ANALYZE
       sample_rows,                -- Sample rows used at last ANALYZE
       analyze_timestamp,          -- Completion time of last ANALYZE
       analyze_count               -- Total ANALYZE count so far
FROM   hologres_statistic.hg_table_statistic
WHERE  unique_name = hologres.hg_internal_statistic_unique_name ('schemaname', 'tablename')
ORDER BY analyze_timestamp DESC;

-- Sample output
 schema_name | table_name |    user_name     | schema_version | total_rows | sample_rows |  analyze_timestamp  | analyze_count
-------------+------------+------------------+----------------+------------+-------------+---------------------+---------------
 public      | test_fnr   |   BASIC$test_fnr |             -1 |        999 |         999 | 2026-03-02 22:05:29 |             2
(1 row)

V3.1 y versiones anteriores:

• Cada tabla tiene de 0 a n registros en la tabla hologres_statistic.hg_table_statistic. 0 registros significa que nunca se ha realizado un ANALYZE, y 1 o más registros significan que se ha ejecutado ANALYZE.

• Si hay dos o más registros, el schema_version de ambos debe ser diferente, ya que los cambios en el esquema de la tabla (como ADD COLUMN, CALL SET_TABLE_PROPERTY, etc.) generan una nueva versión, lo que agrega un nuevo registro de estadísticas. El registro correspondiente al schema_version antiguo deja de utilizarse.

• El siguiente ejemplo de resultado de consulta muestra que la misma tabla tiene 2 registros, y el schema_version del segundo registro es menor que el del primero. Por lo tanto, el segundo registro no es válido y no se utilizará, por lo que no es necesario prestarle atención. Actualmente, Hologres no limpia los registros históricos caducados en la tabla hg_table_statistic, y los usuarios no deben preocuparse por los datos antiguos.

 schema_name | table_name |    user_name     | schema_version | total_rows | sample_rows |  analyze_timestamp  | analyze_count
-------------+------------+------------------+----------------+------------+-------------+---------------------+---------------
 public      | test_fnr   |   BASIC$test_fnr |             13 |        999 |         999 | 2026-03-01 18:05:29 |             2
 public      | test_fnr   |   BASIC$test_fnr |             12 |        999 |         999 | 2026-03-01 08:05:29 |             1
(1 row)

V3.1 y versiones posteriores:

• Cada tabla tiene de 0 a 1 registro en la tabla hologres_statistic.hg_table_statistic. 0 registros significa que nunca se ha realizado un ANALYZE, y 1 registro significa que se ha ejecutado ANALYZE.

• El schema_version se establece uniformemente en -1 (que representa Deprecated).

• Esto significa que muchas operaciones DDL ya no invalidan las estadísticas. Por ejemplo, CALL SET_TABLE_PROPERTY no volverá a activar AUTO ANALYZE, y se seguirán utilizando las estadísticas existentes. En comparación con Hologres V3.0 y versiones anteriores, la frecuencia de activación de AUTO ANALYZE se reduce significativamente.

1. Consulta de conteo de filas y otras estadísticas

La información del conteo de filas se registra en el campo reltuples de la tabla pg_class.

-- relallvisible > 0: the table has row count statistics
-- relallvisible = 0: the row count is unknown; do not rely on reltuples
-- relallvisible < 0: the table has no statistics
SELECT relallvisible, reltuples FROM pg_class WHERE relname = 'test_table';

1. Consulta de estadísticas de columnas

Al consultar la vista pg_stats, puede obtener las estadísticas de todas las columnas de la tabla actual. Por ejemplo, para obtener las estadísticas de la columna ds de test_table:

select * from pg_stats where tablename = 'test_table' and attname = 'ds';

 schemaname | tablename  | attname | inherited | null_frac | avg_width | n_distinct | most_common_vals | most_common_freqs | histogram_bounds | correlation | most_common_elems | most_common_elem_freqs | elem_count_histogram
------------+------------+---------+-----------+-----------+-----------+------------+------------------+-------------------+------------------+-------------+-------------------+------------------------+----------------------
 public     | test_table | ds      | f         |         0 |         4 |          1 | {20241104}       | {1}               |                  |             |                   |                        |
(1 row)

Consulta de tablas con estadísticas faltantes

Hologres proporciona la vista HG_STATS_MISSING (el nombre real de la vista puede variar según la versión) para comprobar las tablas en la base de datos actual que carecen de estadísticas, facilitando la identificación de objetos que requieren un ANALYZE complementario.

Problemas comunes y solución de problemas

1. Posibles razones por las que se devuelven 0 registros desde la tabla hologres_statistic.hg_table_statistic:

• Nunca se ha ejecutado ANALYZE (ni manualmente ni mediante AUTO ANALYZE);

• AUTO ANALYZE no está funcionando o la tabla no ha cumplido las condiciones de activación;

Acciones recomendadas:

• Primero, ejecute manualmente:

ANALYZE schema_name.table_name;

• Si la tabla sigue sin poder ser cubierta por AUTO ANALYZE durante un período prolongado, se recomienda comprobar el interruptor de AUTO ANALYZE y la configuración GUC, o contactar al soporte técnico.

1. Posibles razones para un analyze_timestamp claramente desactualizado:

• AUTO ANALYZE se ha deshabilitado o restringido (como autovacuum_enabled = false);

• AUTO ANALYZE tiene recursos insuficientes o ha fallado (se puede investigar conjuntamente con registros/monitoreo);

Acciones recomendadas:

• Ejecute ANALYZE manualmente una vez y observe los resultados;

• Compruebe:

  • Si hg_enable_start_auto_analyze_worker está habilitado;

  • Si autovacuum_enabled = false se ha establecido erróneamente o si las restricciones GUC relacionadas son demasiado estrictas;

  • Compruebe si hay errores relacionados con tareas de AUTO ANALYZE en el Query Log.

1. Estimación anómala de conteo de filas en planes de consulta (significativamente demasiado baja o demasiado alta)

• Compruebe si la tabla correspondiente carece de estadísticas o tiene estadísticas desactualizadas;

• Compruebe si las columnas de predicado tienen estadísticas (pg_stats) y realice un ANALYZE a nivel de columna en columnas críticas;

• Compruebe si la función de estimación rápida de conteo de filas se ha deshabilitado o no está habilitada.

1. Estadísticas padre-hijo inconsistentes para tablas particionadas o estadísticas faltantes en la tabla padre

• Síntoma: La tabla padre de particiones no tiene registros en hologres_statistic.hg_table_statistic, o total_rows es significativamente menor que la suma de todos los conteos de filas de las tablas secundarias, o la distribución MCV de estadísticas de columnas de partición de la tabla padre está desactualizada (por ejemplo, falta la distribución de ayer en la columna ds de pg_stats);

• Puntos de solución de problemas:

  • Compruebe si el ANALYZE / AUTO ANALYZE incremental de particiones se ha deshabilitado;

SHOW hg_experimental_enable_incremental_analyze;
SHOW hg_experimental_enable_incremental_auto_analyze;

• Utilice la vista HG_STATS_MISSING para comprobar si hay tablas secundarias que no se pueden fusionar;

• Compruebe si hay errores relacionados con tareas de AUTO ANALYZE en el Query Log;

• Ejecute manualmente ANALYZE child_table; en tablas secundarias con estadísticas faltantes, o ejecute ANALYZE partition_parent_table; en la tabla padre durante horas de baja demanda para permitir que el sistema complete y fusione las estadísticas.

1. Ciertas columnas no tienen estadísticas en pg_stats

• Síntoma: La tabla tiene la columna, pero no se encuentran las estadísticas correspondientes en la vista pg_stats.

• Puntos de solución de problemas:

  • Compruebe si las estadísticas se han deshabilitado mediante atributos de columna (enable_analyze = false o enable_auto_analyze = false);

SELECT attoptions
  FROM pg_attribute
 WHERE attrelid = 'tablename'::regclass::oid
   AND attname = 'columnname';
-[ RECORD 1 ]----------------------
attoptions | {enable_analyze=false}

• Confirme si la columna ha participado en ANALYZE (manual o AUTO ANALYZE). Si es necesario, ejecute ANALYZE table_name(col_name); a nivel de columna;

SELECT query_id,
       application_name,
       status,
       query_start,
       query
FROM   hologres.hg_query_log
WHERE  query_start >= now() - interval '1 hour'
  AND  application_name IN ('Hologres SQL Generated BY ANALYZE', 'Hologres SQL Generated BY AUTO ANALYZE')
  AND  query like '%tablename%'
ORDER BY query_start DESC
LIMIT  2;

• Si la columna es de un tipo especial (bytea, jsonb).

• Si la tabla ha ejecutado AUTO ANALYZE pero ninguna columna tiene estadísticas, considere si la tarea de AUTO ANALYZE se ejecutó de manera anómala. Por ejemplo, compruebe si AUTO ANALYZE excedió el tiempo de espera. Dado que auto_analyze_work_statement_timeout tiene un valor predeterminado de 1 hora, si la tarea de AUTO ANALYZE en hologres.hg_query_log tiene una duración >= 3600000, en este caso solo se recopila información de conteo de filas sin estadísticas de columnas.

1. AUTO ANALYZE se ha ejecutado pero el plan de consulta no ha mejorado significativamente

• Síntoma: Se pueden ver registros de AUTO ANALYZE para una tabla específica en hologres.hg_query_log, pero el plan de consulta real sigue utilizando estimaciones de conteo de filas claramente irracionales u órdenes de Join;

• Puntos de solución de problemas:

  • Compruebe si AUTO ANALYZE excedió el tiempo de espera. Dado que auto_analyze_work_statement_timeout tiene un valor predeterminado de 1 hora, si la tarea de AUTO ANALYZE en hologres.hg_query_log tiene una duración >= 3600s, en este caso solo se recopila información de conteo de filas sin estadísticas de columnas.

  • Compruebe si hay Hints, órdenes de Join fijos o GUC heredados a nivel de sesión (como enable_nestloop, etc.) que interfieran con las decisiones del optimizador;

  • Realice un ANALYZE manual en tablas/columnas críticas y luego vuelva a ejecutar la consulta. Si aún no hay mejoras, se recomienda investigar más a fondo conjuntamente con el Query Log, registros del FE o reportando al soporte técnico.

1. Problemas de OOM / límite de memoria excedido causados por estadísticas

• Síntoma: Un Join complejo de múltiples tablas reporta el error Query executor exceeded total memory limitation ..., o el plan selecciona una estrategia de Join extremadamente irracional (como una tabla grande impulsando un Nested Loop de tabla grande, etc.);

• Puntos de solución de problemas:

  • Confirme si las tablas relacionadas carecen de estadísticas o tienen estadísticas severamente desactualizadas (combinando registros en hg_table_statistic y registros de ejecución de AUTO ANALYZE);

  • Realice ANALYZE a nivel de columna en columnas de Join y columnas de filtro. Si es necesario, aumente la precisión del muestreo o habilite la función de estimación rápida de conteo de filas;

  • Si el problema solo ocurre en ciertas distribuciones de datos extremas o escenarios de alta demanda, consulte con el soporte técnico para evaluar si se necesitan ajustes en el modelo de estadísticas o GUC relacionados (como umbrales de AUTO ANALYZE, límites de memoria, etc.).

ANALYZE manual y Serverless computing

• hg_serverless_computing_enable_analyze_statement

  • Descripción: Controla si las instrucciones ANALYZE manuales pueden ejecutarse mediante tareas Serverless.

  • Comportamiento:

    • Si se establece en on (valor predeterminado), el sistema permite descargar las instrucciones ANALYZE a recursos de cómputo Serverless para su ejecución, lo que minimiza el impacto de las tareas de estadísticas en la instancia.

    • Si se establece en off, ANALYZE se ejecuta en los recursos locales de la instancia.

  • Recomendaciones típicas:

    • En instancias Serverless, el valor predeterminado es on, por lo que solo los recursos Serverless completan las tareas de estadísticas.

    • Para solucionar problemas o cuando existen requisitos especiales de uso de recursos, puede establecerlo temporalmente en off para ejecutar explícitamente ANALYZE en los recursos locales.

AUTO ANALYZE y Serverless computing

Al generar tareas de AUTO ANALYZE, el sistema determina si debe usar recursos Serverless y cómo controlar el comportamiento de dichas tareas según los siguientes parámetros GUC:

• hg_auto_analyze_run_with_serverless_computing

  • Descripción: Determina si las tareas de AUTO ANALYZE se ejecutan mediante recursos de cómputo Serverless. El valor predeterminado es off para instancias regulares y on para instancias Serverless.

  • Comportamiento:

    • Si se establece en on, las tareas de AUTO ANALYZE envían los cálculos de muestreo al pool de recursos Serverless.

    • Si se establece en off, AUTO ANALYZE continúa generando las estadísticas mediante los recursos locales de la instancia.

-- Set at the database level
ALTER DATABASE datname SET hg_auto_analyze_run_with_serverless_computing = on;

• hg_auto_analyze_serverless_computing_query_priority

  • Descripción: Define la prioridad de las tareas Serverless de AUTO ANALYZE, con valores entre 1~5. Los valores más altos indican mayor prioridad. El valor predeterminado es 2.

  • Comportamiento:

    • Cuando se habilita AUTO ANALYZE en Serverless, el sistema asigna la prioridad correspondiente a cada tarea de estadísticas mediante SET hg_experimental_serverless_tasks_query_priority = <value>;.

    • Este parámetro resulta útil cuando se comparte un pool de recursos con otras tareas Serverless (como ETL y consultas sin conexión) para controlar la capacidad de apropiación de recursos de las tareas de estadísticas dentro de la cola general.

  • Recomendaciones:

    • En entornos de producción, generalmente se mantiene una prioridad media (como el valor predeterminado 2 o un incremento moderado a 3) para evitar competir por demasiados recursos con los procesos empresariales principales.

    • En escenarios con requisitos muy estrictos de actualización de estadísticas y recursos Serverless suficientes, puede aumentar la prioridad según corresponda.

• hg_auto_analyze_serverless_computing_enable_persisted_snapshot

  • Descripción: Determina si se usa una instantánea persistente (persisted snapshot) en las tareas Serverless de AUTO ANALYZE; es decir, controla si se omite el flush adicional mediante SET hg_experimental_enable_persisted_snapshot = on/off;.

  • El valor predeterminado es off para instancias no Serverless y on para instancias Serverless.

  • Comportamiento:

    • Si se establece en on, las tareas de estadísticas intentan reutilizar la instantánea persistente, lo que reduce la necesidad de activar un flush. Esta opción es más adecuada para estadísticas de alta frecuencia o escenarios con muchas tablas particionadas.

    • Si se establece en off, las tareas de estadísticas intentan usar una instantánea más actualizada, lo cual conviene en escenarios con mayores requisitos de consistencia o aislamiento de versiones específicas.

  • Recomendaciones:

    • No ajuste este parámetro a menos que sea necesario.

Recomendaciones de uso para escenarios de Serverless computing

1. Priorice el uso de Serverless Computing para manejar tareas ANALYZE pesadas

   • Al ejecutar ANALYZE en tablas o tablas externas con volúmenes de datos muy grandes, se recomienda habilitar lo siguiente:

     • ANALYZE manual: set hg_computing_resource = 'serverless'; ANALYZE my_table;.

     • AUTO ANALYZE: ALTER DATABASE mydb SET hg_auto_analyze_run_with_serverless_computing = on;.

   • Esto traslada la presión del cálculo de estadísticas al pool de recursos Serverless y reduce la interferencia con las consultas en línea de la instancia.

2. Establezca la prioridad de las tareas Serverless de AUTO ANALYZE según la importancia del negocio

   • En instancias Serverless, para bases de datos empresariales críticas que son sensibles a la actualización de estadísticas y dependen de datos recientes, puede aumentar adecuadamente el valor de hg_auto_analyze_serverless_computing_query_priority.

   • En instancias regulares, suele ser suficiente usar recursos locales para AUTO ANALYZE.

3. Siga el principio de "pruebas incrementales" antes de ajustar parámetros

   • Los parámetros GUC relacionados con Serverless Computing también son configuraciones avanzadas. Antes de ajustarlos, se recomienda comprobarlos primero en un entorno de prueba o preproducción:

     • Observe la duración de la espera en cola y la ejecución de las tareas de estadísticas en el pool de recursos Serverless.

     • Supervise el impacto en la latencia y el uso de recursos de las consultas empresariales principales.

   • Una vez confirmado que no hay efectos secundarios significativos, implemente los cambios en el entorno de producción por base de datos o por fases.