Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Limitations du langage DML et autres informations relatives à Aurora PostgreSQL Limitless Database Les sections suivantes décrivent les limitations ou apportent des informations supplémentaires concernant les commandes SQL de traitement des données (DML) et de traitement des requêtes dans Aurora PostgreSQL Limitless Database. **Topics** + [ANALYSE](#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) ## ANALYSE La commande `ANALYZE` collecte des statistiques sur le contenu des tables de la base de données. Le planificateur de requêtes utilise ensuite ces statistiques pour déterminer les plans d’exécution les plus efficaces pour les requêtes. Pour en savoir plus, consultez [ANALYZE](https://www.postgresql.org/docs/current/sql-analyze.html) dans la documentation PostgreSQL. Dans Aurora PostgreSQL Limitless Database, la commande `ANALYZE` collecte les statistiques des tables sur tous les routeurs et partitions lors de son exécution. Pour empêcher le calcul de statistiques sur chaque routeur pendant l’exécution de la commande `ANALYZE`, les statistiques des tables sont calculées sur l’un des routeurs, puis copiées sur des routeurs homologues. ## CLUSTER La commande `CLUSTER` réorganise physiquement une table en fonction d’un index. L’index doit déjà avoir été défini dans la table. Dans Aurora PostgreSQL Limitless Database, le clustering s’applique uniquement à la portion de l’index stockée sur chaque partition. Pour en savoir plus, consultez [CLUSTER](https://www.postgresql.org/docs/current/sql-cluster.html) dans la documentation PostgreSQL. ## EXPLAIN Le paramètre suivant est utilisé pour configurer le résultat produit par la commande `EXPLAIN` : + `rds_aurora.limitless_explain_options` : ce qu’il faut inclure dans la sortie `EXPLAIN`. La valeur par défaut est `single_shard_optimization` : elle indique si les plans sont optimisés pour une partition unique, sans toutefois inclure les plans de partition. Dans cet exemple, la sortie `EXPLAIN` n’affiche pas les plans issus des partitions. ``` 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) ``` Maintenant, nous définissons `rds_aurora.limitless_explain_options` pour inclure `shard_plans` et `single_shard_optimization`. Nous pouvons consulter les plans d’exécution des instructions à la fois sur les routeurs et sur les partitions. En outre, nous désactivons le paramètre `enable_seqscan` pour garantir que le scan d’index soit utilisé sur la couche de partition. ``` 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) ``` Pour plus d’informations sur la commande `EXPLAIN`, consultez [EXPLAIN](https://www.postgresql.org/docs/current/sql-explain.html) dans la documentation PostgreSQL. ## INSERT La plupart des commandes `INSERT` sont prises en charge dans Aurora PostgreSQL Limitless Database. PostgreSQL ne propose pas de commande explicite `UPSERT`, mais permet d’exécuter des instructions `INSERT ... ON CONFLICT`. La commande `INSERT ... ON CONFLICT` n’est pas prise en charge si l’action de conflit comporte une sous-requête ou une fonction 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. ``` Pour plus d’informations sur la commande `INSERT`, consultez [INSERT](https://www.postgresql.org/docs/current/sql-insert.html) dans la documentation PostgreSQL. ## UPDATE La mise à jour de la clé de partition n’est pas prise en charge. Supposons que vous disposiez d’une table partitionnée nommée `customers`, avec une clé de partition `customer_id`. Les instructions DML suivantes sont à l’origine d’erreurs : ``` 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 ``` Pour mettre à jour une clé de partition, vous devez d’abord exécuter la commande `DELETE` sur la ligne contenant la clé de partition, puis `INSERT` sur une nouvelle ligne avec la valeur de clé de partition mise à jour. Pour plus d’informations sur la commande `UPDATE`, consultez [Mise à jour de données](https://www.postgresql.org/docs/current/dml-update.html) dans la documentation PostgreSQL. ## VACUUM Vous pouvez effectuer un vacuum sur les tables partitionnées et sur les tables de référence. Les fonctions `VACUUM` suivantes sont entièrement prises en charge dans Aurora PostgreSQL Limitless Database : + VACUUM + [ANALYSE](#limitless-reference.DML-limitations.ANALYZE) + DISABLE\$1PAGE\$1SKIPPING + FREEZE + FULL + INDEX\$1CLEANUP + PARALLEL + PROCESS\$1TOAST + TRUNCATE + VERBOSE Sur Aurora PostgreSQL Limitless Database, la fonction `VACUUM` présente les limitations suivantes : + L’extension [pg\$1visibility\$1map](https://www.postgresql.org/docs/current/pgvisibility.html) n’est pas prise en charge. + La vérification des index inutilisés avec la vue [pg\$1stat\$1all\$1indexes](https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ALL-INDEXES-VIEW) n’est pas prise en charge. + Les vues unifiées 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) et [pg\$1stats](https://www.postgresql.org/docs/current/view-pg-stats.html) ne sont pas disponibles. Pour plus d’informations sur la commande `VACUUM`, consultez [VACUUM](https://www.postgresql.org/docs/current/sql-vacuum.html) dans la documentation PostgreSQL. Pour plus d’informations sur le fonctionnement du vacuum dans Aurora PostgreSQL Limitless Database, consultez [Récupération de l’espace de table via une opération de vacuum](limitless-vacuum.md).