Limitations du langage DDL et autres informations relatives à Aurora PostgreSQL Limitless Database

Pour en savoir plus sur les fonctionnalités non prises en charge, consultez Constaintes.

Les valeurs par défaut sont prises en charge. Pour plus d’informations, consultez Valeurs par défaut.

Les index ne sont pas tous visibles sur les routeurs lorsque vous utilisez \d table_name ou des commandes similaires. Utilisez plutôt la vue pg_catalog.pg_indexes pour obtenir des index, comme illustré dans l’exemple suivant.

SET rds_aurora.limitless_create_table_mode='sharded';
SET rds_aurora.limitless_create_table_shard_key='{"id"}';
CREATE TABLE items (id int PRIMARY KEY, val int);
CREATE INDEX items_my_index on items (id, val);

postgres_limitless=> SELECT * FROM pg_catalog.pg_indexes WHERE tablename='items';

 schemaname | tablename |   indexname    | tablespace |                                indexdef
------------+-----------+----------------+------------+------------------------------------------------------------------------
 public     | items     | items_my_index |            | CREATE INDEX items_my_index ON ONLY public.items USING btree (id, val)
 public     | items     | items_pkey     |            | CREATE UNIQUE INDEX items_pkey ON ONLY public.items USING btree (id)
(2 rows)

Les contraintes simples qui utilisent des opérateurs de comparaison avec des littéraux sont prises en charge. Les expressions et contraintes plus complexes qui nécessitent des validations de fonctions ne sont pas prises en charge, comme le montrent les exemples suivants.

CREATE TABLE my_table (
    id  INT CHECK (id > 0)                                     -- supported
  , val INT CHECK (val > 0 AND val < 1000)                     -- supported
  , tag TEXT CHECK (length(tag) > 0)                           -- not supported: throws "Expression inside CHECK constraint is not supported"
  , op_date TIMESTAMP WITH TIME ZONE CHECK (op_date <= now())  -- not supported: throws "Expression inside CHECK constraint is not supported"
);

Vous pouvez attribuer des noms explicites aux contraintes, comme illustré dans l’exemple suivant.

CREATE TABLE my_table (
    id  INT CONSTRAINT positive_id  CHECK (id > 0)
  , val INT CONSTRAINT val_in_range CHECK (val > 0 AND val < 1000)
);

Vous pouvez utiliser une syntaxe de contrainte au niveau de la table avec la contrainte CHECK, comme illustré dans l’exemple suivant.

CREATE TABLE my_table (
    id INT CONSTRAINT positive_id  CHECK (id > 0)
  , min_val INT CONSTRAINT min_val_in_range CHECK (min_val > 0 AND min_val < 1000)
  , max_val INT
  , CONSTRAINT max_val_in_range CHECK (max_val > 0 AND max_val < 1000 AND max_val > min_val)
);

Les contraintes d’exclusion ne sont pas prises en charge dans Aurora PostgreSQL Limitless Database.

Pour plus d’informations, consultez Clés étrangères.

Les contraintes NOT NULL sont prises en charge sans aucune restriction.

Étant donné que la clé primaire impose des contraintes uniques, elle est soumise aux mêmes restrictions que celles des contraintes uniques. Autrement dit :

Les exemples suivants illustrent l’utilisation des clés primaires.

-- Create a standard table.
CREATE TABLE public.my_table (
    item_id INT
  , location_code INT
  , val INT
  , comment text
);

-- Change the table to a sharded table using the 'item_id' and 'location_code' columns as shard keys.
CALL rds_aurora.limitless_alter_table_type_sharded('public.my_table', ARRAY['item_id', 'location_code']);

Tentative d’ajout d’une clé primaire qui ne contient pas de clé de partition :

-- Add column 'item_id' as the primary key.
-- Invalid because the primary key doesnt include all columns from the shard key:
-- 'location_code' is part of the shard key but not part of the primary key
ALTER TABLE public.my_table ADD PRIMARY KEY (item_id); -- ERROR

-- add column "val" as primary key
-- Invalid because primary key does not include all columns from shard key:
--  item_id and location_code iare part of shard key but not part of the primary key
ALTER TABLE public.my_table ADD PRIMARY KEY (item_id); -- ERROR

Tentative d’ajout d’une clé primaire qui contient une clé de partition :

-- Add the 'item_id' and 'location_code' columns as the primary key.
-- Valid because the primary key contains the shard key.
ALTER TABLE public.my_table ADD PRIMARY KEY (item_id, location_code); -- OK

-- Add the 'item_id', 'location_code', and 'val' columns as the primary key.
-- Valid because the primary key contains the shard key.
ALTER TABLE public.my_table ADD PRIMARY KEY (item_id, location_code, val); -- OK

Remplacez une table standard par une table de référence.

-- Create a standard table.
CREATE TABLE zipcodes (zipcode INT PRIMARY KEY, details VARCHAR);

-- Convert the table to a reference table.
CALL rds_aurora.limitless_alter_table_type_reference('public.zipcode');

Pour plus d’informations sur la création de tables partitionnées et de tables de référence, consultez Création de tables Aurora PostgreSQL Limitless Database.

Dans les tables partitionnées, la clé unique doit contenir la clé de partition, c’est-à-dire que la clé de partition doit être un sous-ensemble de la clé unique. Cette vérification est effectuée lors du changement du type de table en table partitionnée. Aucune restriction n’est appliquée aux tables de référence.

CREATE TABLE customer (
    customer_id INT NOT NULL
  , zipcode INT
  , email TEXT UNIQUE
);

Les contraintes UNIQUE au niveau de la table sont prises en charge, comme illustré dans l’exemple suivant.

CREATE TABLE customer (
    customer_id INT NOT NULL
  , zipcode INT
  , email TEXT
  , CONSTRAINT zipcode_and_email UNIQUE (zipcode, email)
);

L’exemple suivant montre l’utilisation conjointe d’une clé primaire et d’une clé unique. Les deux clés doivent inclure la clé de partition.

SET rds_aurora.limitless_create_table_mode='sharded';
SET rds_aurora.limitless_create_table_shard_key='{"p_id"}';
CREATE TABLE t1 (
p_id BIGINT NOT NULL,
c_id BIGINT NOT NULL,
PRIMARY KEY (p_id),
UNIQUE (p_id, c_id)
);

Vous pouvez créer des extensions, comme dans PostgreSQL.

CREATE EXTENSION [ IF NOT EXISTS ] extension_name
    [ WITH ] [ SCHEMA schema_name ]
             [ VERSION version ]
             [ CASCADE ]

Pour plus d’informations, consultez CREATE EXTENSION dans la documentation PostgreSQL.

Les DDL suivants sont pris en charge :

ALTER EXTENSION name UPDATE [ TO new_version ]

ALTER EXTENSION name SET SCHEMA new_schema

Pour plus d’informations, consultez ALTER EXTENSION dans la documentation PostgreSQL.

Vous pouvez supprimer des extensions, comme dans PostgreSQL.

DROP EXTENSION [ IF EXISTS ] name [, ...] [ CASCADE | RESTRICT ]

Pour plus d’informations, consultez DROP EXTENSION dans la documentation PostgreSQL.

Vous ne pouvez pas ajouter ou supprimer des objets membres des extensions.

ALTER EXTENSION name ADD member_object

ALTER EXTENSION name DROP member_object

rds_aurora.limitless_pgstattuple(relation_name)

rds_aurora.limitless_pgstattuple(relation_name, subcluster_id)

rds_aurora.limitless_pgstatindex(relation_name)

rds_aurora.limitless_pgstatindex(relation_name, subcluster_id)

rds_aurora.limitless_pgstatginindex(relation_name)

rds_aurora.limitless_pgstatginindex(relation_name, subcluster_id)

rds_aurora.limitless_pgstathashindex(relation_name)

rds_aurora.limitless_pgstathashindex(relation_name, subcluster_id)

rds_aurora.limitless_pg_relpages(relation_name)

rds_aurora.limitless_pg_relpages(relation_name, subcluster_id)

rds_aurora.limitless_pgstattuple_approx(relation_name)

rds_aurora.limitless_pgstattuple_approx(relation_name, subcluster_id)

Il est possible de créer des fonctions comme dans Aurora PostgreSQL, toutefois, la volatilité ne peut pas être changée lors d’un remplacement.

Pour plus d’informations, consultez CREATE FUNCTION dans la documentation PostgreSQL.

Vous pouvez modifier des fonctions, comme dans Aurora PostgreSQL, à l’exception du changement de leur volatilité.

Pour plus d’informations, consultez ALTER FUNCTION dans la documentation PostgreSQL.

Vous pouvez supprimer des fonctions, comme dans Aurora PostgreSQL.

DROP FUNCTION [ IF EXISTS ] name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ] [, ...]
    [ CASCADE | RESTRICT ]

Pour plus d’informations, consultez DROP FUNCTION dans la documentation PostgreSQL.

Lorsque vous distribuez une fonction ou une procédure, elle ne traite que les données délimitées par la plage de clés de cette partition. Dans les cas où la fonction ou la procédure essaie d’accéder aux données d’une autre partition, les résultats renvoyés par la fonction ou procédure distribuée seront différents de ceux renvoyés par une fonction ou procédure non distribuée.

Par exemple, vous créez une fonction contenant des requêtes qui toucheront plusieurs partitions, puis vous appelez la procédure rds_aurora.limitless_distribute_function pour la distribuer. Lorsque vous invoquez cette fonction en fournissant des arguments pour une clé de partition, il est probable que les résultats de son exécution seront limités par les valeurs présentes dans cette partition. Ces résultats diffèrent de ceux obtenus lorsque la fonction n’est pas distribuée.

Prenons l’exemple de la fonction func suivante, avec la table partitionnée customers et la clé de partition customer_id.

postgres_limitless=> CREATE OR REPLACE FUNCTION func(c_id integer, sc integer) RETURNS int
    language SQL
    volatile
    AS $$
    UPDATE customers SET score = sc WHERE customer_id = c_id RETURNING score;
    $$;

Nous distribuons cette fonction :

SELECT rds_aurora.limitless_distribute_function('func(integer, integer)', ARRAY['c_id'], 'customers');

Voici quelques exemples de plans de requête.

EXPLAIN(costs false, verbose true) SELECT func(27+1,10);

                    QUERY PLAN
 --------------------------------------------------
  Foreign Scan
    Output: (func((27 + 1), 10))
    Remote SQL:  SELECT func((27 + 1), 10) AS func
  Single Shard Optimized
 (4 rows)

EXPLAIN(costs false, verbose true)
 SELECT * FROM customers,func(customer_id, score) WHERE customer_id=10 AND score=27;

                          QUERY PLAN
 ---------------------------------------------------------------------
  Foreign Scan
    Output: customer_id, name, score, func
    Remote SQL:  SELECT customers.customer_id,
      customers.name,
      customers.score,
      func.func
     FROM public.customers,
      LATERAL func(customers.customer_id, customers.score) func(func)
    WHERE ((customers.customer_id = 10) AND (customers.score = 27))
  Single Shard Optimized
 (10 rows)

L’exemple suivant illustre une procédure utilisant les paramètres IN et OUT en tant qu’arguments.

CREATE OR REPLACE FUNCTION get_data(OUT id INTEGER, IN arg_id INT)
    AS $$
    BEGIN
        SELECT customer_id,
        INTO id
        FROM customer
        WHERE customer_id = arg_id;
    END;
    $$ LANGUAGE plpgsql;

L’exemple suivant illustre la distribution de la procédure utilisant uniquement les paramètres IN.

EXPLAIN(costs false, verbose true) SELECT * FROM get_data(1);

             QUERY PLAN
 -----------------------------------
  Foreign Scan
    Output: id
    Remote SQL:  SELECT customer_id
     FROM get_data(1) get_data(id)
  Single Shard Optimized
 (6 rows)

La fonction setval n’est pas prise en charge. Pour plus d’informations, consultez Fonctions de manipulation de séquence dans la documentation PostgreSQL.

Les options suivantes ne sont pas prises en charge.

CREATE [{ TEMPORARY | TEMP} | UNLOGGED] SEQUENCE
    [[ NO ] CYCLE]

Pour plus d’informations, consultez CREATE SEQUENCE dans la documentation PostgreSQL.

Les options suivantes ne sont pas prises en charge.

ALTER SEQUENCE
    [[ NO ] CYCLE]

Pour plus d’informations, consultez ALTER SEQUENCE dans la documentation PostgreSQL.

La commande ALTER TABLE n’est pas compatible avec les séquences.

postgres_limitless=> CREATE SEQUENCE s;
CREATE SEQUENCE

postgres_limitless=> SELECT nextval('s');

 nextval
---------
       1
(1 row)

postgres_limitless=> SELECT * FROM pg_sequence WHERE seqrelid='s'::regclass;

 seqrelid | seqtypid | seqstart | seqincrement | seqmax | seqmin | seqcache | seqcycle 
----------+----------+----------+--------------+--------+--------+----------+----------
    16960 |       20 |        1 |            1 |  10000 |      1 |        1 | f
(1 row)

% connect to another router
postgres_limitless=> SELECT nextval('s');

 nextval 
---------
   10001
(1 row)

postgres_limitless=> SELECT * FROM pg_sequence WHERE seqrelid='s'::regclass;

 seqrelid | seqtypid | seqstart | seqincrement | seqmax | seqmin | seqcache | seqcycle 
----------+----------+----------+--------------+--------+--------+----------+----------
    16959 |       20 |    10001 |            1 |  20000 |  10001 |        1 | f
(1 row)

postgres_limitless=> DROP SEQUENCE s;
DROP SEQUENCE

postgres_limitless=> CREATE SEQUENCE s;
CREATE SEQUENCE

postgres_limitless=> ALTER SEQUENCE s RESTART 500;
ALTER SEQUENCE

postgres_limitless=> SELECT nextval('s');

 nextval
---------
     500
(1 row)

postgres_limitless=> SELECT currval('s');

 currval
---------
     500
(1 row)

postgres=# CREATE TABLE t(a bigint primary key, b bigint);
CREATE TABLE

postgres=# CREATE SEQUENCE s minvalue 0 START 0;
CREATE SEQUENCE

postgres=# INSERT INTO t VALUES (nextval('s'), currval('s'));                                                                                             
INSERT 0 1

postgres=# INSERT INTO t VALUES (nextval('s'), currval('s'));
INSERT 0 1

postgres=# SELECT * FROM t;

 a | b
---+---
 0 | 0
 1 | 1
(2 rows)

postgres=# ALTER SEQUENCE s RESTART 10000;
ALTER SEQUENCE

postgres=# INSERT INTO t VALUES (nextval('s'), currval('s'));                                                                                             
INSERT 0 1

postgres=# SELECT * FROM t;

   a   |   b
-------+-------
     0 |     0
     1 |     1
 10000 | 10000
(3 rows)

Cette vue montre l’état et la configuration d’une séquence distribuée. Les colonnes minvalue, maxvalue, start, inc et cache ont la même signification que dans la vue pg_sequences et indiquent les options avec lesquelles la séquence a été créée. La colonne lastval indique la dernière valeur allouée ou réservée dans un objet de séquence distribuée. Cela ne signifie pas que la valeur a déjà été utilisée, puisque les routeurs conservent les fragments de séquence localement.

postgres_limitless=> SELECT * FROM rds_aurora.limitless_distributed_sequence WHERE sequence_name='test_serial_b_seq';

 schema_name |   sequence_name   | lastval | minvalue |  maxvalue  | start | inc | cache
-------------+-------------------+---------+----------+------------+-------+-----+-------
 public      | test_serial_b_seq | 1250000 |        1 | 2147483647 |     1 |   1 |     1
(1 row)

Cette vue montre les métadonnées de séquence distribuée et agrège les métadonnées de séquence provenant des nœuds du cluster. Elle utilise les colonnes suivantes :

postgres_limitless=> SELECT * FROM rds_aurora.limitless_sequence_metadata WHERE sequence_name='test_serial_b_seq' order by subcluster_id;

 subcluster_id |   sequence_name   | schema_name | active_minvalue | active_maxvalue | reserved_minvalue | reserved_maxvalue | chunk_size | chunk_state | local_last_value 
---------------+-------------------+-------------+-----------------+-----------------+-------------------+-------------------+------------+-------------+------------------
 1             | test_serial_b_seq | public      |          500001 |          750000 |           1000001 |           1250000 |     250000 |           1 |           550010
 2             | test_serial_b_seq | public      |          250001 |          500000 |            750001 |           1000000 |     250000 |           1 |                 
(2 rows)

Si la taille des fragments n’est pas suffisamment grande et que le taux de transactions est élevé, les processus en arrière-plan risquent de ne pas avoir le temps de demander de nouveaux fragments avant que les fragments actifs ne soient épuisés. Cela peut entraîner une contention et des événements d’attente tels que LIMITLESS:AuroraLimitlessSequenceReplace, LWLock:LockManager , Lockrelation et LWlock:bufferscontent.

Augmentez la valeur du paramètre rds_aurora.limitless_sequence_chunk_size.

Dans PostgreSQL, la mise en cache des séquences s’effectue au niveau de la session. Chaque session alloue des valeurs de séquence successives lors d’un accès à l’objet de séquence et augmente la last_value de l’objet de la séquence en conséquence. Par la suite, les utilisations de nextval au sein de la même session retournent directement les valeurs préallouées, sans interaction avec l’objet de séquence.

Tous les numéros alloués mais non utilisés au cours d’une session sont perdus à la fin de cette dernière, ce qui entraîne des « trous » dans la séquence. Cette situation peut provoquer une consommation rapide du sequence_chunk et générer des contentions et événements d’attente comme LIMITLESS:AuroraLimitlessSequenceReplace, LWLock:LockManager , Lockrelation et LWlock:bufferscontent.

Réduisez le paramètre de mise en cache des séquences.