DMLlimitations et autres informations relatives à la base de données Aurora Postgre SQL Limitless - 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.

DMLlimitations et autres informations relatives à la base de données Aurora Postgre SQL Limitless

Les rubriques suivantes décrivent les limites ou fournissent des informations supplémentaires sur les SQL commandes de traitement DML des requêtes dans la base de données Aurora Postgre SQL Limitless.

ANALYZE

La ANALYZE commande 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 plus d'informations, consultez ANALYZEla SQL documentation Postgre.

Dans la base de données Aurora Postgre SQL Limitless, la ANALYZE commande 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 les ANALYZE exécutions, les statistiques des tables sont calculées sur l'un des routeurs, puis copiées sur des routeurs homologues.

CLUSTER

La CLUSTER commande réorganise physiquement une table en fonction d'un index. L'index doit déjà avoir été défini dans la table. Dans la base de données Aurora Postgre SQL Limitless, le clustering est local à la partie de l'index présente sur chaque partition.

Pour plus d'informations, consultez CLUSTERla SQL documentation Postgre.

EXPLAIN

Vous utilisez le paramètre suivant pour configurer le résultat de la EXPLAIN commande :

  • rds_aurora.limitless_explain_options— Ce qu'il faut inclure dans le EXPLAIN résultat. La valeur par défaut est la single_shard_optimization suivante : si les plans sont optimisés pour un seul fragment est indiqué, mais les plans de partition ne sont pas inclus.

Dans cet exemple, la EXPLAIN sortie n'affiche pas les plans issus de 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 le rds_aurora.limitless_explain_options pour inclure shard_plans etsingle_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 enable_seqscan paramètre 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 EXPLAIN commande, consultez EXPLAINla SQL documentation Postgre.

INSERT

La plupart des INSERT commandes sont prises en charge dans la base de données Aurora Postgre SQL Limitless.

Postgre SQL n'a pas de UPSERT commande explicite, mais il supporte les INSERT ... ON CONFLICT instructions.

INSERT ... ON CONFLICTn'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 INSERT commande, consultez INSERTla SQL documentation Postgre.

UPDATE

La mise à jour de la clé de partition n'est pas prise en charge. Par exemple, vous avez une table fragmentée appeléecustomers, avec une clé de partition. customer_id Les DML instructions 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 accéder à DELETE la ligne contenant la clé de partition, puis à INSERT une nouvelle ligne avec la valeur de clé de partition mise à jour.

Pour plus d'informations sur la UPDATE commande, consultez la section Mise à jour des données dans la SQL documentation Postgre.

VACUUM

Vous pouvez passer l'aspirateur à la fois sur des tables découpées et sur des tables de référence. Les VACUUM fonctions suivantes sont entièrement prises en charge dans la base de données Aurora Postgre SQL Limitless :

  • VACUUM

  • ANALYZE

  • DISABLE_PAGE_SKIPPING

  • FREEZE

  • FULL

  • INDEX_CLEANUP

  • PARALLEL

  • PROCESS_TOAST

  • TRUNCATE

  • VERBOSE

VACUUMsur Aurora Postgre, la base de données SQL Limitless présente les limites suivantes :

Pour plus d'informations sur la VACUUM commande, consultez VACUUMla SQL documentation Postgre. Pour plus d'informations sur le fonctionnement de l'aspirateur dans la base de données Aurora Postgre SQL Limitless, consultez. Récupérer de l'espace de rangement en passant l'aspirateur