

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Limitazioni DML e altre informazioni per Aurora PostgreSQL Limitless Database
<a name="limitless-reference.DML-limitations"></a>

I seguenti argomenti descrivono le limitazioni o forniscono ulteriori informazioni per i comandi DML e di elaborazione delle query SQL in Aurora PostgreSQL Limitless Database.

**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>

Il comando `ANALYZE` raccoglie statistiche sul contenuto delle tabelle nel database. Successivamente, il pianificatore di query utilizza queste statistiche per determinare i piani di esecuzione più efficienti per le query. Per ulteriori informazioni, consulta [ANALYZE](https://www.postgresql.org/docs/current/sql-analyze.html) nella documentazione di PostgreSQL.

In Aurora PostgreSQL Limitless Database, il comando `ANALYZE` raccoglie le statistiche delle tabelle su tutti i router e gli shard durante l’esecuzione.

Per impedire il calcolo delle statistiche su ogni router durante le esecuzioni di `ANALYZE`, le statistiche delle tabelle vengono calcolate su uno dei router e quindi copiate sui router peer.

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

Il comando `CLUSTER` riordina fisicamente una tabella in base a un indice. L’indice deve essere già stato definito nella tabella. In Aurora PostgreSQL Limitless Database, il clustering è locale alla parte dell’indice presente su ogni shard.

Per ulteriori informazioni, consulta [CLUSTER](https://www.postgresql.org/docs/current/sql-cluster.html) nella documentazione di PostgreSQL.

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

Si utilizza il seguente parametro per configurare l’output del comando `EXPLAIN`:
+ `rds_aurora.limitless_explain_options`: cosa includere nell’output `EXPLAIN`. Il valore predefinito è `single_shard_optimization`: viene mostrato se i piani sono ottimizzati per shard singolo, ma i piani shard non sono inclusi.

In questo esempio, l’output `EXPLAIN` non mostra i piani ricavati dagli shard.

```
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)
```

Ora impostiamo l’opzione `rds_aurora.limitless_explain_options` per includere `shard_plans` e`single_shard_optimization`. Possiamo visualizzare i piani di esecuzione delle istruzioni sia sui router che sugli shard. Inoltre, disabilitiamo il parametro `enable_seqscan` per far sì che la scansione dell’indice venga utilizzata sul livello shard.

```
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)
```

Per ulteriori informazioni sul comando `EXPLAIN`, consulta [EXPLAIN](https://www.postgresql.org/docs/current/sql-explain.html) nella documentazione di PostgreSQL.

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

La maggior parte dei comandi `INSERT` è supportata in Aurora PostgreSQL Limitless Database.

PostgreSQL non ha un comando `UPSERT` esplicito, ma supporta le istruzioni `INSERT ... ON CONFLICT`.

`INSERT ... ON CONFLICT` non è supportato se l’azione di conflitto ha una sottoquery o una funzione mutabile:

```
-- 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.
```

Per ulteriori informazioni sul comando `INSERT`, consulta [INSERT](https://www.postgresql.org/docs/current/sql-insert.html) nella documentazione di PostgreSQL.

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

L’aggiornamento della chiave shard non è supportato. Ad esempio, si dispone di una tabella sottoposta a sharding denominata `customers`, con una chiave shard `customer_id`. Le seguenti istruzioni DML causano errori:

```
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
```

Per aggiornare una chiave shard, è necessario prima `DELETE` la riga con la chiave shard key, quindi `INSERT` una nuova riga con il valore della chiave shard aggiornato.

Per ulteriori informazioni sul comando `UPDATE`, consulta [Updating data](https://www.postgresql.org/docs/current/dml-update.html) nella documentazione di PostgreSQL.

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

È possibile eseguire l’operazione di vacuum sia sulle tabelle sottoposte a sharding che su quelle di riferimento. Le seguenti funzioni `VACUUM` sono completamente supportate in Aurora PostgreSQL Limitless Database.
+ VACUUM
+ [ANALYZE](#limitless-reference.DML-limitations.ANALYZE)
+ DISABLE\$1PAGE\$1SKIPPING
+ FREEZE
+ FULL
+ INDEX\$1CLEANUP
+ PARALLEL
+ PROCESS\$1TOAST
+ TRUNCATE
+ VERBOSE

`VACUUM` su Aurora PostgreSQL Limitless Database presenta le seguenti limitazioni:
+ L’estensione [pg\$1visibility\$1map](https://www.postgresql.org/docs/current/pgvisibility.html) non è supportata.
+ Il controllo degli indici non utilizzati con la vista [pg\$1stat\$1all\$1indexes](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ALL-INDEXES-VIEW) non è supportato.
+ Le viste consolidate per [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) e [pg\$1stats](https://www.postgresql.org/docs/current/view-pg-stats.html) non sono implementate.

Per ulteriori informazioni sul comando `VACUUM`, consulta [VACUUM](https://www.postgresql.org/docs/current/sql-vacuum.html) nella documentazione di PostgreSQL. Per ulteriori informazioni su come funziona l’operazione di vacuum in Aurora PostgreSQL Limitless Database, consulta [Recupero dello spazio di archiviazione tramite il processo di vacuum](limitless-vacuum.md).