Limitaciones del DDL y otra información para Base de datos ilimitada de Aurora PostgreSQL

Para obtener más información sobre lo que no se admite, consulte Restricciones.

Se admiten los valores predeterminados. Para obtener más información, consulte Valores predeterminados.

No todos los índices son visibles en los enrutadores cuando se utiliza \d table_name o comandos similares. En su lugar, utilice la vista pg_catalog.pg_indexes para obtener índices, tal y como se muestra en el siguiente ejemplo.

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)

Se admiten restricciones simples que implican operadores de comparación con literales. No se admiten expresiones ni restricciones más complejas que requieren validaciones de funciones, tal como se muestra en los siguientes ejemplos.

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"
);

También puede asignar nombres explícitos a las restricciones, tal como se muestra en el siguiente ejemplo.

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

Puede utilizar la sintaxis de restricciones de nivel de tabla con la restricción CHECK, tal como se muestra en el siguiente ejemplo.

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

Las restricciones de exclusión no se admiten en Base de datos ilimitada de Aurora PostgreSQL.

Para obtener más información, consulte Claves externas.

Las restricciones NOT NULL se admiten sin restricciones.

La clave principal implica restricciones únicas y, por lo tanto, las mismas restricciones a las restricciones únicas se aplican a la clave principal. Esto significa:

En los siguientes ejemplos se ilustra el uso de claves principales.

-- 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']);

Aquí se intenta añadir una clave principal que no contiene una clave de partición:

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

Aquí se intenta añadir una clave principal que contiene una clave de partición:

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

Cambie una tabla estándar por una tabla de referencia.

-- 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');

Para obtener más información sobre la creación de tablas particionadas y de referencia, consulte Creación de tablas de Base de datos ilimitada de Aurora PostgreSQL.

En las tablas particionadas, la clave única debe contener la clave de partición, es decir, la clave de partición debe ser un subconjunto de la clave única. Esto se comprueba al cambiar el tipo de tabla a particionada. En las tablas de referencia no hay ninguna restricción.

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

Se admiten restricciones UNIQUE en el nivel de tabla, tal como se muestra en el siguiente ejemplo.

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

El siguiente ejemplo muestra el uso conjunto de una clave principal y una clave única. Ambas claves deben incluir la clave de partición.

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

Puede crear extensiones, como en PostgreSQL.

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

Para obtener más información, consulte CREATE EXTENSION en la documentación de PostgreSQL.

Se admiten los siguientes DDL:

ALTER EXTENSION name UPDATE [ TO new_version ]

ALTER EXTENSION name SET SCHEMA new_schema

Para obtener más información, consulte ALTER EXTENSION en la documentación de PostgreSQL.

Puede eliminar extensiones, como en PostgreSQL.

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

Para obtener más información, consulte DROP EXTENSION en la documentación de PostgreSQL.

No se pueden agregar ni eliminar objetos miembros de extensiones.

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)

Puede crear funciones, como en Aurora PostgreSQL, menos cambiar su volatilidad al sustituirlas.

Para obtener más información, consulte CREATE FUNCTION en la documentación de PostgreSQL.

Puede modificar funciones, como en Aurora PostgreSQL, menos modificar su volatilidad.

Para obtener más información, consulte ALTER FUNCTION en la documentación de PostgreSQL.

Puede eliminar funciones, como en Aurora PostgreSQL.

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

Para obtener más información, consulte DROP FUNCTION en la documentación de PostgreSQL.

Al distribuir una función o un procedimiento, solo se ocupa de los datos que están limitados por el rango de claves de partición de dicha partición. En los casos en que la función o el procedimiento intenten acceder a los datos de una partición diferente, los resultados devueltos por la función o el procedimiento distribuidos serán diferentes de los que no estén distribuidos.

Por ejemplo, se crea una función que contiene consultas que tocarán varias particiones, pero después se llama al procedimiento rds_aurora.limitless_distribute_function para distribuirla. Al invocar esta función proporcionando argumentos para una clave de partición, es probable que los resultados de su ejecución estén limitados por los valores presentes en esa partición. Estos resultados son distintos de los que se obtienen sin distribuir la función.

Considere la función func en la que tenemos la tabla particionada customers con la clave de partición 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;
    $$;

Ahora distribuimos esta función:

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

A continuación se muestra un ejemplo de planes de consulta.

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)

El siguiente ejemplo muestra un procedimiento con los parámetros IN y OUT como argumentos.

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;

El siguiente ejemplo distribuye el procedimiento utilizando únicamente parámetros 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)

No se admite la función setval. Para obtener más información, consulte Sequence Manipulation Functions en la documentación de PostgreSQL.

No se admiten las siguientes opciones.

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

Para obtener más información, consulte CREATE SEQUENCE en la documentación de PostgreSQL.

No se admiten las siguientes opciones.

ALTER SEQUENCE
    [[ NO ] CYCLE]

Para obtener más información, consulte ALTER SEQUENCE en la documentación de PostgreSQL.

El comando ALTER TABLE no admite secuencias.

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)

Esta vista muestra el estado y la configuración de una secuencia distribuida. Las columnas minvalue, maxvalue, start, inc y cache tienen el mismo significado en la vista pg_sequences y muestran las opciones con las que se ha creado la secuencia. La columna lastval muestra el último valor asignado o reservado en un objeto de secuencia distribuida. Esto no significa que el valor ya se haya utilizado, ya que los enrutadores mantienen los fragmentos de secuencia de forma local.

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)

Esta vista muestra los metadatos de secuencia distribuida y agrega los metadatos de secuencia de los nodos del clúster. Utiliza las siguientes columnas:

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 el tamaño del fragmento no es lo suficientemente grande y la tasa de transacciones es alta, es posible que los trabajadores en segundo plano no tengan tiempo suficiente para solicitar nuevos fragmentos antes de que se agoten los fragmentos activos. Esto puede provocar contención y eventos de espera como LIMITLESS:AuroraLimitlessSequenceReplace, LWLock:LockManager, Lockrelation y LWlock:bufferscontent.

Aumente el valor del parámetro rds_aurora.limitless_sequence_chunk_size.

En PostgreSQL, el almacenamiento en caché de secuencias se produce en el nivel de sesión. Cada sesión asigna valores de secuencia sucesivos durante un acceso al objeto de secuencia y aumenta los last_value del objeto de secuencia en consecuencia. Luego, los siguientes usos de nextval en esa sesión simplemente devuelven los valores preasignados sin tocar el objeto de secuencia.

Los números asignados pero no utilizados en una sesión se pierden al finalizar la sesión, lo que genera huecos en la secuencia. Esto puede consumir el sequence_chunk rápidamente y provocar contención y eventos de espera como LIMITLESS:AuroraLimitlessSequenceReplace, LWLock:LockManager, Lockrelation y LWlock:bufferscontent.

Reduzca la configuración de la caché de secuencias.