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à. # Aspirazione e analisi manuale delle tabelle Se il database viene cancellato dal processo di aspirazione automatica, è consigliabile evitare di eseguire gli aspirapolvere manuali sull'intero database con troppa frequenza. Un aspirapolvere manuale potrebbe causare I/O carichi inutili o picchi di CPU e potrebbe anche non riuscire a rimuovere eventuali tuple morte. Fate funzionare gli aspirapolvere manuali solo se è veramente necessario, ad esempio quando il rapporto tra tuple vive e tuple morte è basso, o quando vi sono lunghi table-by-table intervalli tra gli autovacuum. Inoltre, è consigliabile utilizzare gli aspirapolvere manuali quando l'attività dell'utente è minima. Autovacuum mantiene inoltre aggiornate le statistiche di una tabella. Quando esegui il `ANALYZE` comando manualmente, ricostruisce queste statistiche invece di aggiornarle. La ricostruzione delle statistiche quando sono già aggiornate dal normale processo di autovacuum potrebbe causare l'utilizzo delle risorse di sistema. Si consiglia di eseguire i comandi [VACUUM](https://www.postgresql.org/docs/current/sql-vacuum.html) e [ANALYZE](https://www.postgresql.org/docs/current/sql-analyze.html) manualmente nei seguenti scenari: + Nelle ore di punta più basse sui tavoli più affollati, quando l'aspirazione automatica potrebbe non essere sufficiente. + Subito dopo il caricamento in blocco dei dati nella tabella di destinazione. In questo caso, l'esecuzione `ANALYZE` manuale ricostruisce completamente le statistiche, il che è un'opzione migliore rispetto all'attesa dell'avvio dell'autovacuum. + Per aspirare le tabelle temporanee (autovacuum non può accedervi). Per ridurre l' I/O impatto dell'esecuzione dei `ANALYZE` comandi `VACUUM` and sull'attività simultanea del database, è possibile utilizzare il parametro. `vacuum_cost_delay` In molte situazioni, i comandi di manutenzione come `VACUUM` e `ANALYZE` non devono essere completati rapidamente. Tuttavia, questi comandi non dovrebbero interferire con la capacità del sistema di eseguire altre operazioni sul database. Per evitare che ciò accada, è possibile attivare ritardi di vuoto basati sui costi utilizzando il `vacuum_cost_delay` parametro. Per impostazione predefinita, questo parametro è disabilitato per i comandi emessi `VACUUM` manualmente. Per abilitarlo, impostalo su un valore diverso da zero. ## Esecuzione delle operazioni di aspirazione e pulizia in parallelo L'opzione [PARALLEL](https://www.postgresql.org/docs/current/sql-vacuum.html) del `VACUUM` comando utilizza i worker paralleli per le fasi di vuoto dell'indice e di pulizia dell'indice ed è disabilitata per impostazione predefinita. Il numero di lavoratori paralleli (il grado di parallelismo) è determinato dal numero di indici nella tabella e può essere specificato dall'utente. Se esegui `VACUUM` operazioni parallele senza un argomento intero, il grado di parallelismo viene calcolato in base al numero di indici nella tabella. I seguenti parametri ti aiutano a configurare l'vacuuming parallelo in Amazon RDS for PostgreSQL e Aurora PostgreSQL: + [max\$1worker\$1processes imposta il numero massimo di processi di lavoro simultanei.](https://www.postgresql.org/docs/current/runtime-config-resource.html) + [min\$1parallel\$1index\$1scan\$1size](https://www.postgresql.org/docs/current/runtime-config-query.html) imposta la quantità minima di dati dell'indice che devono essere scansionati per prendere in considerazione una scansione parallela. + [max\$1parallel\$1maintenance\$1workers](https://www.postgresql.org/docs/current/runtime-config-resource.html) imposta il numero massimo di worker paralleli che possono essere avviati da un singolo comando di utilità. **Nota** L'opzione viene utilizzata solo per l'aspirazione. `PARALLEL` Non influisce sul comando. `ANALYZE` L'esempio seguente illustra il comportamento del database quando si utilizza manualmente `VACUUM` e `ANALYZE` su un database. Ecco una tabella di esempio in cui l'autovacuum è stato disabilitato (solo a scopo illustrativo; la disabilitazione dell'autovacuum non è consigliata): ``` create table t1 ( a int, b int, c int ); alter table t1 set (autovacuum_enabled=false); ``` ``` apgl=> \d+ t1 Table "public.t1" Column | Type | Collation | Nullable | Default | Storage | Stats target | Description --------+---------+-----------+----------+---------+---------+--------------+------------- a | integer | | | | plain | | b | integer | | | | plain | | c | integer | | | | plain | | Access method: heap Options: autovacuum_enabled=false ``` Aggiungi 1 milione di righe alla tabella t1: ``` apgl=> select count(*) from t1; count 1000000 (1 row) ``` Statistiche della tabella t1: ``` select * from pg_stat_all_tables where relname='t1'; -[ RECORD 1 ]-------+-------- relid | 914744 schemaname | public relname | t1 seq_scan | 0 seq_tup_read | 0 idx_scan | idx_tup_fetch | n_tup_ins | 1000000 n_tup_upd | 0 n_tup_del | 0 n_tup_hot_upd | 0 n_live_tup | 1000000 n_dead_tup | 0 n_mod_since_analyze | 1000000 last_vacuum | last_autovacuum | last_analyze | last_autoanalyze | vacuum_count | 0 autovacuum_count | 0 analyze_count | 0 autoanalyze_count | 0 ``` Aggiungi un indice: ``` create index i2 on t1 (b,a); ``` Esegui il `EXPLAIN` comando (Piano 1): ``` Bitmap Heap Scan on t1 (cost=10521.17..14072.67 rows=5000 width=4) Recheck Cond: (a = 5) → Bitmap Index Scan on i2 (cost=0.00..10519.92 rows=5000 width=0) Index Cond: (a = 5) (4 rows) ``` Esegui il `EXPLAIN ANALYZE` comando (Piano 2): ``` explain (analyze,buffers,costs off) select a from t1 where b = 5; QUERY PLAN Bitmap Heap Scan on t1 (actual time=0.023..0.024 rows=1 loops=1) Recheck Cond: (b = 5) Heap Blocks: exact=1 Buffers: shared hit=4 → Bitmap Index Scan on i2 (actual time=0.016..0.016 rows=1 loops=1) Index Cond: (b = 5) Buffers: shared hit=3 Planning Time: 0.054 ms Execution Time: 0.076 ms (9 rows) ``` I `EXPLAIN ANALYZE ` comandi `EXPLAIN ` and mostrano piani diversi, perché l'autovacuum è stato disabilitato sulla tabella e il `ANALYZE` comando non è stato eseguito manualmente. Ora aggiorniamo un valore nella tabella e rigeneriamo il piano: `EXPLAIN ANALYZE` ``` update t1 set a=8 where b=5; explain (analyze,buffers,costs off) select a from t1 where b = 5; ``` Il `EXPLAIN ANALYZE` comando (Plan 3) ora visualizza: ``` apgl=> explain (analyze,buffers,costs off) select a from t1 where b = 5; QUERY PLAN Bitmap Heap Scan on t1 (actual time=0.075..0.076 rows=1 loops=1) Recheck Cond: (b = 5) Heap Blocks: exact=1 Buffers: shared hit=5 → Bitmap Index Scan on i2 (actual time=0.017..0.017 rows=2 loops=1) Index Cond: (b = 5) Buffers: shared hit=3 Planning Time: 0.053 ms Execution Time: 0.125 ms ``` Se confrontate i costi tra il Piano 2 e il Piano 3, noterete le differenze nei tempi di pianificazione ed esecuzione, perché non abbiamo ancora raccolto le statistiche. Ora eseguiamo un manuale `ANALYZE` sul tavolo, quindi controlliamo le statistiche e rigeneriamo il piano: ``` apgl=> analyze t1 apgl→ ; ANALYZE Time: 212.223 ms apgl=> select * from pg_stat_all_tables where relname='t1'; -[ RECORD 1 ]-------+------------------------------ relid | 914744 schemaname | public relname | t1 seq_scan | 3 seq_tup_read | 1000000 idx_scan | 3 idx_tup_fetch | 3 n_tup_ins | 1000000 n_tup_upd | 1 n_tup_del | 0 n_tup_hot_upd | 0 n_live_tup | 1000000 n_dead_tup | 1 n_mod_since_analyze | 0 last_vacuum | last_autovacuum | last_analyze | 2023-04-15 11:39:02.075089+00 last_autoanalyze | vacuum_count | 0 autovacuum_count | 0 analyze_count | 1 autoanalyze_count | 0 Time: 148.347 ms ``` Esegui il `EXPLAIN ANALYZE` comando (Plan 4): ``` apgl=> explain (analyze,buffers,costs off) select a from t1 where b = 5; QUERY PLAN Index Only Scan using i2 on t1 (actual time=0.022..0.023 rows=1 loops=1) Index Cond: (b = 5) Heap Fetches: 1 Buffers: shared hit=4 Planning Time: 0.056 ms Execution Time: 0.068 ms (6 rows) Time: 138.462 ms ``` Se confrontate tutti i risultati del piano dopo aver analizzato manualmente la tabella e raccolto le statistiche, noterete che il Piano 4 dell'ottimizzatore è migliore degli altri e riduce anche il tempo di esecuzione delle query. Questo esempio mostra quanto sia importante eseguire attività di manutenzione sul database. ## Riscrivere un'intera tabella con VACUUM FULL L'esecuzione del `VACUUM ` comando con il `FULL` parametro riscrive l'intero contenuto di una tabella in un nuovo file su disco senza spazio aggiuntivo e restituisce lo spazio inutilizzato al sistema operativo. Questa operazione è molto più lenta e richiede un `ACCESS EXCLUSIVE` blocco su ogni tabella. Richiede inoltre spazio su disco aggiuntivo, poiché scrive una nuova copia della tabella e rilascia la vecchia copia solo dopo il completamento dell'operazione. `VACUUM FULL`può essere utile nei seguenti casi:**** + Quando si desidera recuperare una notevole quantità di spazio dai tavoli. + Quando si desidera recuperare spazio occupato in tabelle a chiave non primaria. Se il database è in grado di tollerare tempi di inattività, `VACUUM FULL` se il database è in grado di tollerare tempi di inattività, è consigliabile utilizzarle quando si hanno tabelle a chiave non primaria. Poiché `VACUUM FULL` richiede più blocchi rispetto ad altre operazioni, è più costoso eseguirlo su database cruciali. Per sostituire questo metodo, è possibile utilizzare l'`pg_repack `estensione, descritta nella [sezione successiva](pg-repack.md). Questa opzione è simile `VACUUM FULL` ma richiede un blocco minimo ed è supportata sia da Amazon RDS for PostgreSQL che da Aurora PostgreSQL compatibile.