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 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
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 sortieEXPLAIN. La valeur par défaut estsingle_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
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
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
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
-
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 :
-
L’extension pg_visibility_map
n’est pas prise en charge. -
La vérification des index inutilisés avec la vue pg_stat_all_indexes
n’est pas prise en charge. -
Les vues unifiées de pg_stat_user_indexes
, pg_class et pg_stats ne sont pas disponibles.
Pour plus d’informations sur la commande VACUUM, consultez VACUUM