

# Limitaciones del DML y otra información para Base de datos ilimitada de Aurora PostgreSQL
<a name="limitless-reference.DML-limitations"></a>

En los siguientes temas se describen las limitaciones o se proporciona más información sobre los comandos SQL de procesamiento de consultas y DML en Base de datos ilimitada de Aurora PostgreSQL.

**Topics**
+ [ANALYZE](#limitless-reference.DML-limitations.ANALYZE)
+ [CLUSTER](#limitless-reference.DML-limitations.CLUSTER)
+ [EXPLAIN](#limitless-reference.DML-limitations.EXPLAIN)
+ [INSERT](#limitless-reference.DML-limitations.INSERT)
+ [UPDATE](#limitless-reference.DML-limitations.UPDATE)
+ [VACUUM](#limitless-reference.DML-limitations.VACUUM)

## ANALYZE
<a name="limitless-reference.DML-limitations.ANALYZE"></a>

El comando `ANALYZE` recopila estadísticas sobre el contenido de las tablas de la base de datos. Posteriormente, el planificador de consultas utiliza estas estadísticas para ayudar a determinar los planes de ejecución más eficaces para las consultas. Para obtener más información, consulte [ANALYZE](https://www.postgresql.org/docs/current/sql-analyze.html) en la documentación de PostgreSQL.

En Base de datos ilimitada de Aurora PostgreSQL, el comando `ANALYZE` recopila estadísticas de tablas en todos los enrutadores y particiones cuando se ejecuta.

Para evitar el cálculo de estadísticas de todos los enrutadores durante las ejecuciones de `ANALYZE`, las estadísticas de la tabla se calculan en uno de los enrutadores y, a continuación, se copian en los enrutadores homólogos.

## CLUSTER
<a name="limitless-reference.DML-limitations.CLUSTER"></a>

El comando `CLUSTER` reordena físicamente una tabla en función de un índice. El índice ya debe estar definido en la tabla. En Base de datos ilimitada de Aurora PostgreSQL, la agrupación es local en la parte del índice que está presente en cada partición.

Para obtener más información, consulte [CLUSTER](https://www.postgresql.org/docs/current/sql-cluster.html) en la documentación de PostgreSQL.

## EXPLAIN
<a name="limitless-reference.DML-limitations.EXPLAIN"></a>

Utilice el siguiente parámetro para configurar la salida del comando `EXPLAIN`:
+ `rds_aurora.limitless_explain_options`: indica lo que se debe incluir en la salida de `EXPLAIN`. El valor predeterminado es `single_shard_optimization` y muestra si los planes están optimizados para una sola partición, aunque los planes para particiones no están incluidos.

En este ejemplo, la salida de `EXPLAIN` no muestra los planes de las particiones.

```
postgres_limitless=> EXPLAIN SELECT * FROM employees where id =25;

                      QUERY PLAN
------------------------------------------------------
 Foreign Scan  (cost=100.00..101.00 rows=100 width=0)
 Single Shard Optimized
(2 rows)
```

Ahora configuraremos `rds_aurora.limitless_explain_options` para que incluya `shard_plans` y `single_shard_optimization`. Podemos ver los planes de ejecución de las instrucciones tanto en los enrutadores como en las particiones. Además, desactivamos el parámetro `enable_seqscan` para exigir que el escaneo de índices se utilice en la capa de particiones.

```
postgres_limitless=> SET rds_aurora.limitless_explain_options = shard_plans, single_shard_optimization;
SET

postgres_limitless=> SET enable_seqscan = OFF;
SET

postgres_limitless=> EXPLAIN SELECT * FROM employees WHERE id = 25;

                                                        QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------
 Foreign Scan  (cost=100.00..101.00 rows=100 width=0)
   Remote Plans from Shard postgres_s4:
         Index Scan using employees_ts00287_id_idx on employees_ts00287 employees_fs00003  (cost=0.14..8.16 rows=1 width=15)
           Index Cond: (id = 25)
 Single Shard Optimized
(5 rows)
```

Para obtener más información acerca del comando `EXPLAIN`, consulte [EXPLAIN](https://www.postgresql.org/docs/current/sql-explain.html) en la documentación de PostgreSQL.

## INSERT
<a name="limitless-reference.DML-limitations.INSERT"></a>

Base de datos ilimitada de Aurora PostgreSQL admite la mayoría de comandos `INSERT`.

PostgreSQL no tiene un comando `UPSERT` explícito, pero admite las instrucciones `INSERT ... ON CONFLICT`.

`INSERT ... ON CONFLICT` no se admite si la acción conflictiva tiene una subconsulta o una función mutable:

```
-- RANDOM is a mutable function.
INSERT INTO sharded_table VALUES (1, 100) ON CONFLICT (id) DO UPDATE SET other_id = RANDOM();

ERROR: Aurora Limitless Tables doesn't support pushdown-unsafe functions with DO UPDATE clauses.
```

Para obtener más información acerca del comando `INSERT`, consulte [INSERT](https://www.postgresql.org/docs/current/sql-insert.html) en la documentación de PostgreSQL.

## UPDATE
<a name="limitless-reference.DML-limitations.UPDATE"></a>

La actualización de la clave de partición es incompatible. Por ejemplo, tiene una tabla particionada llamada `customers`, con una clave de partición `customer_id`. Las siguientes instrucciones DML provocan errores:

```
postgres_limitless=> UPDATE customers SET customer_id = 11 WHERE customer_id =1;
ERROR:  Shard key column update is not supported

postgres_limitless=> UPDATE customers SET customer_id = 11 WHERE customer_name='abc';
ERROR:  Shard key column update is not supported
```

Para actualizar una clave de partición, primero hay que `DELETE` la fila con la clave de partición y, a continuación, `INSERT` una nueva fila con el valor de la clave de partición actualizada.

Para obtener más información acerca del comando `UPDATE`, consulte [Updating data](https://www.postgresql.org/docs/current/dml-update.html) en la documentación de PostgreSQL.

## VACUUM
<a name="limitless-reference.DML-limitations.VACUUM"></a>

Puede vaciar tanto en las tablas particionadas como en las tablas de referencia. Base de datos ilimitada de Aurora PostgreSQL admite por completo las siguientes funciones `VACUUM`:
+ VACUUM
+ [ANALYZE](#limitless-reference.DML-limitations.ANALYZE)
+ DISABLE\$1PAGE\$1SKIPPING
+ FREEZE
+ FULL
+ INDEX\$1CLEANUP
+ PARALLEL
+ PROCESS\$1TOAST
+ TRUNCATE
+ VERBOSE

`VACUUM` en Base de datos ilimitada de Aurora PostgreSQL tiene las siguientes limitaciones:
+ No se admite la extensión [pg\$1visibility\$1map](https://www.postgresql.org/docs/current/pgvisibility.html).
+ No se admite la comprobación de índices no utilizados con la vista [pg\$1stat\$1all\$1indexes](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ALL-INDEXES-VIEW).
+ No se implementan las vistas consolidadas de [pg\$1stat\$1user\$1indexes](https://www.postgresql.org/docs/current/monitoring-stats.html), [pg\$1class](https://www.postgresql.org/docs/current/catalog-pg-class.html) y [pg\$1stats](https://www.postgresql.org/docs/current/view-pg-stats.html).

Para obtener más información acerca del comando `VACUUM`, consulte [VACUUM](https://www.postgresql.org/docs/current/sql-vacuum.html) en la documentación de PostgreSQL. Para obtener más información sobre cómo funciona el vacío en Base de datos ilimitada de Aurora PostgreSQL, consulte [Recuperación de espacio de almacenamiento mediante el vaciado](limitless-vacuum.md).