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 DDL et autres informations relatives à la base de données Aurora PostgreSQL Limitless

Les rubriques suivantes décrivent les limites ou fournissent des informations supplémentaires sur les commandes DDL SQL dans la base de données Aurora PostgreSQL Limitless.

ALTER TABLE

La ALTER TABLE commande est généralement prise en charge dans la base de données Aurora PostgreSQL Limitless. Pour plus d'informations, consultez ALTER TABLE dans la documentation de PostgreSQL.

Limites

ALTER TABLEprésente les limites suivantes pour les options prises en charge.

Options non prises en charge

Certaines options ne sont pas prises en charge car elles dépendent de fonctionnalités non prises en charge, telles que les déclencheurs.

Les options suivantes au niveau du tableau pour ALTER TABLE ne sont pas prises en charge :

Les options suivantes au niveau des colonnes pour ALTER TABLE ne sont pas prises en charge :

CREATE DATABASE

Dans Aurora PostgreSQL Limitless Database, seules les bases de données illimitées sont prises en charge.

En cours CREATE DATABASE d'exécution, les bases de données créées avec succès sur un ou plusieurs nœuds peuvent échouer sur d'autres nœuds, car la création de base de données est une opération non transactionnelle. Dans ce cas, les objets de base de données créés avec succès sont automatiquement supprimés de tous les nœuds dans un délai prédéterminé afin de maintenir la cohérence du groupe de partitions de base de données. Pendant ce temps, la recréation d'une base de données portant le même nom peut générer une erreur indiquant que la base de données existe déjà.

Les options suivantes sont prises en charge :

Les options suivantes ne sont pas prises en charge :

CREATE INDEX

CREATE INDEX CONCURRENTLYest pris en charge pour les tables fragmentées :

CREATE INDEX CONCURRENTLY index_name ON table_name(column_name);

CREATE UNIQUE INDEXest pris en charge pour tous les types de tables :

CREATE UNIQUE INDEX index_name ON table_name(column_name);

CREATE UNIQUE INDEX CONCURRENTLYn'est pas pris en charge :

CREATE UNIQUE INDEX CONCURRENTLY index_name ON table_name(column_name);

Pour plus d'informations, consultez UNIQUE. Pour des informations générales sur la création d'index, consultez CREATE INDEX dans la documentation de PostgreSQL.

CREATE SCHEMA

CREATE SCHEMAavec un élément de schéma n'est pas pris en charge :

CREATE SCHEMA my_schema CREATE TABLE (column_name INT);

Cela génère une erreur similaire à la suivante :

ERROR: CREATE SCHEMA with schema elements is not supported

CREATE TABLE

Les relations dans CREATE TABLE les instructions ne sont pas prises en charge, par exemple :

CREATE TABLE orders (orderid int, customerId int, orderDate date) WITH (autovacuum_enabled = false);

IDENTITYles colonnes ne sont pas prises en charge, par exemple :

CREATE TABLE orders (orderid INT GENERATED ALWAYS AS IDENTITY);

La base de données Aurora PostgreSQL Limitless prend en charge jusqu'à 54 caractères pour les noms de table fragmentés.

CREATE TABLE AS

Pour créer une table en utilisantCREATE TABLE AS, vous devez utiliser la rds_aurora.limitless_create_table_mode variable. Pour les tableaux fragmentés, vous devez également utiliser la rds_aurora.limitless_create_table_shard_key variable. Pour de plus amples informations, veuillez consulter Création de tables illimitées à l'aide de variables.

-- Set the variables.
SET rds_aurora.limitless_create_table_mode='sharded';
SET rds_aurora.limitless_create_table_shard_key='{"a"}';

CREATE TABLE ctas_table AS SELECT 1 a;

-- "source" is the source table whose columns and data types are used to create the new "ctas_table2" table.
CREATE TABLE ctas_table2 AS SELECT a,b FROM source;

Vous ne pouvez pas les utiliser CREATE TABLE AS pour créer des tables de référence, car elles nécessitent des contraintes de clé primaire. CREATE TABLE ASne propage pas les clés primaires vers les nouvelles tables.

Pour des informations générales, consultez CREATE TABLE AS dans la documentation de PostgreSQL.

DROP DATABASE

Vous pouvez supprimer les bases de données que vous avez créées.

La DROP DATABASE commande s'exécute de manière asynchrone en arrière-plan. Pendant son exécution, vous recevrez un message d'erreur si vous essayez de créer une nouvelle base de données portant le même nom.

SELECT INTO

SELECT INTOest fonctionnellement similaire à. CREATE TABLE AS Vous devez utiliser la rds_aurora.limitless_create_table_mode variable. Pour les tableaux fragmentés, vous devez également utiliser la rds_aurora.limitless_create_table_shard_key variable. Pour de plus amples informations, veuillez consulter Création de tables illimitées à l'aide de variables.

-- Set the variables.
SET rds_aurora.limitless_create_table_mode='sharded';
SET rds_aurora.limitless_create_table_shard_key='{"a"}';

-- "source" is the source table whose columns and data types are used to create the new "destination" table.
SELECT * INTO destination FROM source;

Actuellement, l'SELECT INTOopération est effectuée via le routeur, et non directement via les partitions. Par conséquent, les performances peuvent être lentes.

Pour des informations générales, consultez SELECT INTO dans la documentation de PostgreSQL.

Constraints

Les limitations suivantes s'appliquent aux contraintes de la base de données Aurora PostgreSQL Limitless.

Pour plus d'informations, consultez la section Contraintes dans la documentation de PostgreSQL.

Valeurs par défaut

La base de données Aurora PostgreSQL Limitless prend en charge les expressions dans les valeurs par défaut.

L'exemple suivant montre l'utilisation des valeurs par défaut.

CREATE TABLE t (
    a INT DEFAULT 5,
    b TEXT DEFAULT 'NAN',
    c NUMERIC
);

CALL rds_aurora.limitless_alter_table_type_sharded('t', ARRAY['a']);
INSERT INTO t DEFAULT VALUES;
SELECT * FROM t;

 a |  b  | c 
---+-----+---
 5 | NAN |
(1 row)

Les expressions sont prises en charge, comme indiqué dans l'exemple suivant.

CREATE TABLE t1 (a NUMERIC DEFAULT random());

L'exemple suivant ajoute une nouvelle colonne qui est NOT NULL et possède une valeur par défaut.

ALTER TABLE t ADD COLUMN d BOOLEAN NOT NULL DEFAULT FALSE;
SELECT * FROM t;

 a |  b  | c | d 
---+-----+---+---
 5 | NAN |   | f
(1 row)

L'exemple suivant modifie une colonne existante avec une valeur par défaut.

ALTER TABLE t ALTER COLUMN c SET DEFAULT 0.0;
INSERT INTO t DEFAULT VALUES;
SELECT * FROM t;

 a |  b  | c   |  d  
---+-----+-----+-----
 5 | NAN |     | f
 5 | NAN | 0.0 | f
(2 rows)

L'exemple suivant supprime une valeur par défaut.

ALTER TABLE t ALTER COLUMN a DROP DEFAULT;
INSERT INTO t DEFAULT VALUES;
SELECT * FROM t;

 a |  b  | c   |  d  
---+-----+-----+-----
 5 | NAN |     | f
 5 | NAN | 0.0 | f
   | NAN | 0.0 | f
(3 rows)

Pour plus d'informations, consultez la section Valeurs par défaut dans la documentation de PostgreSQL.

Extensions

Les extensions PostgreSQL suivantes sont prises en charge dans la base de données Aurora PostgreSQL Limitless :

La plupart des extensions PostgreSQL ne sont actuellement pas prises en charge dans la base de données Aurora PostgreSQL Limitless. Toutefois, vous pouvez toujours utiliser le paramètre de configuration shared_preload_libraries (SPL) pour charger des extensions dans le cluster de base de données principal Aurora PostgreSQL. Ils sont également chargés dans la base de données Aurora PostgreSQL Limitless, mais ils risquent de ne pas fonctionner correctement.

Par exemple, vous pouvez charger l'pg_hint_planextension, mais le fait de la charger ne garantit pas que les indications transmises dans les commentaires de requête seront utilisées.

Vous pouvez utiliser les pg_available_extension_versions fonctions pg_available_extensions et pour rechercher les extensions prises en charge dans la base de données Aurora PostgreSQL Limitless.

Les extensions suivantes DDLs sont prises en charge :

Les extensions suivantes DDLs ne sont pas prises en charge :

différences entre pg_buffercache dans la base de données Aurora PostgreSQL Limitless

Dans la base de données Aurora PostgreSQL Limitless, lorsque vous installez l'extension pg_buffercache et que vous utilisez la vue, vous recevez des informations relatives à pg_buffercache la mémoire tampon uniquement en provenance du nœud auquel vous êtes actuellement connecté : le routeur. De même, l'utilisation de la fonction pg_buffercache_summary ou pg_buffercache_usage_counts fournit des informations uniquement à partir du nœud connecté.

Vous pouvez avoir de nombreux nœuds et avoir besoin d'accéder aux informations de la mémoire tampon à partir de n'importe quel nœud pour diagnostiquer efficacement les problèmes. Par conséquent, Limitless Database fournit les fonctions suivantes :

En saisissant l'ID de sous-cluster de n'importe quel nœud, qu'il s'agisse d'un routeur ou d'une partition, vous pouvez facilement accéder aux informations de mémoire tampon spécifiques à ce nœud. Ces fonctions sont directement disponibles lorsque vous installez l'pg_buffercacheextension dans la base de données illimitée.

Les colonnes affichées dans la limitless_pg_buffercache vue sont légèrement différentes de celles de la pg_buffercache vue :

Les colonnes limitless_pg_buffercache_summary et les limitless_pg_buffercache_usage_counts vues sont les mêmes que celles des vues normales pg_buffercache_summary et des pg_buffercache_usage_counts vues, respectivement.

En utilisant ces fonctions, vous pouvez accéder à des informations détaillées sur le cache tampon sur tous les nœuds de votre environnement de base de données Limitless, ce qui permet un diagnostic et une gestion plus efficaces de vos systèmes de base de données.

différences entre pgstattuple dans la base de données Aurora PostgreSQL Limitless

Dans Aurora PostgreSQL, l'extension pgstattuple ne prend actuellement pas en charge les tables étrangères, les tables partitionnées ou les index partitionnés. Toutefois, dans la base de données Aurora PostgreSQL Limitless, les objets créés par les utilisateurs font souvent partie de ces types non pris en charge. Bien qu'il existe des tables et des index réguliers (par exemple, les tables de catalogue et leurs index), la plupart des objets résident sur des nœuds étrangers, ce qui en fait des objets étrangers pour le routeur.

Nous reconnaissons l'importance de cette extension pour obtenir des statistiques au niveau des tuples, ce qui est crucial pour des tâches telles que l'élimination des ballonnements et la collecte d'informations diagnostiques. Par conséquent, la base de données Aurora PostgreSQL Limitless prend en charge l'extension dans des bases de pgstattuple données illimitées.

La base de données Aurora PostgreSQL Limitless inclut les fonctions suivantes dans le schéma : rds_aurora

Clés étrangères

Les contraintes de clé étrangère (FOREIGN KEY) sont prises en charge avec certaines restrictions :

Options à clé étrangère

Les clés étrangères sont prises en charge dans la base de données Aurora PostgreSQL Limitless pour certaines options DDL. Le tableau suivant répertorie les options prises en charge et non prises en charge entre les tables de base de données Aurora PostgreSQL Limitless.

Exemples

Fonctions

Les fonctions sont prises en charge dans la base de données Aurora PostgreSQL Limitless.

Les fonctions suivantes DDLs sont prises en charge :

Répartition des fonctions

Lorsque toutes les instructions d'une fonction sont ciblées sur une seule partition, il est avantageux de transférer l'ensemble de la fonction vers la partition cible. Le résultat est ensuite retransmis au routeur, au lieu de démêler la fonction du routeur lui-même. La fonctionnalité de transfert des fonctions et des procédures stockées est utile pour les clients qui souhaitent exécuter leur fonction ou leur procédure stockée au plus près de la source de données, à savoir le shard.

Pour distribuer une fonction, créez d'abord la fonction, puis appelez la rds_aurora.limitless_distribute_function procédure de distribution. Cette fonction utilise la syntaxe suivante :

SELECT rds_aurora.limitless_distribute_function('function_prototype', ARRAY['shard_key'], 'collocating_table');

La fonction prend les paramètres suivants :

Pour identifier la partition sur laquelle exécuter cette fonction, le système prend l'ARRAY['shard_key']argument, le hache et trouve la partition collocating_table qui héberge la plage contenant cette valeur de hachage.

Volatilité des fonctions

Vous pouvez déterminer si une fonction est immuable, stable ou volatile en vérifiant sa provolatile valeur dans la vue pg_proc. La provolatile valeur indique si le résultat de la fonction dépend uniquement de ses arguments d'entrée ou s'il est affecté par des facteurs extérieurs.

La valeur est l'une des suivantes :

Les exemples suivants présentent des fonctions volatiles.

SELECT proname, provolatile FROM pg_proc WHERE proname='pg_sleep';

 proname  | provolatile
----------+-------------
 pg_sleep | v
(1 row)

SELECT proname, provolatile FROM pg_proc WHERE proname='uuid_generate_v4';

     proname      | provolatile
------------------+-------------
 uuid_generate_v4 | v
(1 row)

SELECT proname, provolatile FROM pg_proc WHERE proname='nextval';

 proname | provolatile
---------+-------------
 nextval | v
(1 row)

La modification de la volatilité d'une fonction existante n'est pas prise en charge dans la base de données Aurora PostgreSQL Limitless. Cela s'applique à la fois aux CREATE OR REPLACE FUNCTION commandes ALTER FUNCTION et, comme indiqué dans les exemples suivants.

-- Create an immutable function
CREATE FUNCTION immutable_func1(name text) RETURNS text language plpgsql
AS $$
BEGIN
    RETURN name;
END;
$$IMMUTABLE;

-- Altering the volatility throws an error
ALTER FUNCTION immutable_func1 STABLE;

-- Replacing the function with altered volatility throws an error
CREATE OR REPLACE FUNCTION immutable_func1(name text) RETURNS text language plpgsql
AS $$
BEGIN
    RETURN name;
END;
$$VOLATILE;

Nous vous recommandons vivement d'attribuer les volatilités correctes aux fonctions. Par exemple, si votre fonction utilise plusieurs tables ou fait référence SELECT à des objets de base de données, ne la définissez pas commeIMMUTABLE. Si le contenu de la table change, l'immuabilité est rompue.

Aurora PostgreSQL SELECT autorise des fonctions immuables internes, mais les résultats peuvent être incorrects. La base de données Aurora PostgreSQL Limitless peut renvoyer à la fois des erreurs et des résultats incorrects. Pour plus d'informations sur la volatilité des fonctions, consultez la section Catégories de volatilité des fonctions dans la documentation de PostgreSQL.

Séquences

Les séquences nommées sont des objets de base de données qui génèrent des numéros uniques par ordre croissant ou décroissant. CREATE SEQUENCEcrée un nouveau générateur de numéros de séquence. L'unicité des valeurs de séquence est garantie.

Lorsque vous créez une séquence nommée dans la base de données Aurora PostgreSQL Limitless, un objet de séquence distribué est créé. La base de données Aurora PostgreSQL Limitless distribue ensuite des fragments de valeurs de séquence ne se chevauchant pas sur tous les routeurs de transactions distribués (routeurs). Les segments sont représentés sous forme d'objets de séquence locaux sur les routeurs ; par conséquent, les opérations de séquence telles que nextval et currval sont exécutées localement. Les routeurs fonctionnent indépendamment et demandent de nouveaux fragments à partir de la séquence distribuée en cas de besoin.

Pour plus d'informations sur les séquences, consultez CREATE SEQUENCE dans la documentation de PostgreSQL.

Demande d'un nouveau morceau

Vous configurez la taille des segments alloués sur les routeurs à l'aide du rds_aurora.limitless_sequence_chunk_size paramètre. La valeur par défaut est 250000. Chaque routeur possède initialement deux segments : actif et réservé. Les fragments actifs sont utilisés pour configurer les objets de séquence locaux (paramètre minvalue etmaxvalue), et les fragments réservés sont stockés dans une table de catalogue interne. Lorsqu'un segment actif atteint la valeur minimale ou maximale, il est remplacé par le segment réservé. Pour ce faire, c'ALTER SEQUENCEest utilisé en interne, AccessExclusiveLock c'est-à-dire acquis.

Les programmes de travail en arrière-plan s'exécutent toutes les 10 secondes sur les nœuds du routeur pour scanner les séquences à la recherche de fragments réservés utilisés. Si un fragment utilisé est trouvé, le travailleur demande un nouveau morceau à partir de la séquence distribuée. Assurez-vous de définir une taille de fragment suffisamment grande pour que les travailleurs en arrière-plan aient suffisamment de temps pour en demander de nouveaux. Les demandes à distance ne se produisent jamais dans le contexte des sessions utilisateur, ce qui signifie que vous ne pouvez pas demander directement une nouvelle séquence.

Limites

Les limitations suivantes s'appliquent aux séquences dans la base de données Aurora PostgreSQL Limitless :

Options non prises en charge

Les options suivantes ne sont pas prises en charge pour les séquences dans la base de données Aurora PostgreSQL Limitless.

Exemples

Vues de séquence

La base de données Aurora PostgreSQL Limitless fournit les vues suivantes pour les séquences.

Résolution des problèmes de séquence

Les problèmes suivants peuvent survenir avec les séquences.

La figure suivante montre les événements d'attente provoqués par des problèmes de séquence.