Limitations du langage DML et autres informations relatives à Aurora PostgreSQL Limitless Database - Amazon Aurora

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.

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

  • DISABLE_PAGE_SKIPPING

  • FREEZE

  • FULL

  • INDEX_CLEANUP

  • PARALLEL

  • PROCESS_TOAST

  • TRUNCATE

  • VERBOSE

Sur Aurora PostgreSQL Limitless Database, la fonction VACUUM présente les limitations suivantes :

Pour plus d’informations sur la commande VACUUM, consultez VACUUM 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.