InforSupports

nextval() en Vertica: diferencias con PostgreSQL y cómo auditar secuencias

Written by

Francisco

in

Versión probada: Vertica 11.x — sintaxis y vistas de catálogo vigentes también en 12.x, 23.x, 24.x y la línea actual 26.x, sin cambios.

Un caso común al revisar un DDL heredado en Vertica: encontrar una columna definida con DEFAULT nextval('esquema.secuencia') y necesitar confirmar que esa secuencia realmente existe, antes de asumir que el DDL es válido.

id int NOT NULL DEFAULT nextval('public.seq_ejemplo')

nextval() en Vertica vs. PostgreSQL

Vertica sí soporta DEFAULT nextval('esquema.secuencia') en la definición de una columna, igual que PostgreSQL — pero con una diferencia importante que suele generar confusión a quienes vienen de ese motor: Vertica no crea secuencias automáticamente. En PostgreSQL, una columna SERIAL crea su secuencia asociada de forma implícita; en Vertica, la secuencia debe existir previamente, creada de forma explícita con CREATE SEQUENCE, antes de poder referenciarla en cualquier DEFAULT nextval(...).

Verificar si una secuencia existe

La vista correcta del catálogo del sistema para esto es v_catalog.sequences:

SELECT *
FROM v_catalog.sequences
WHERE sequence_schema = 'public'
  AND sequence_name = 'seq_ejemplo';

Para listar todas las secuencias existentes en la base de datos, con su valor actual:

SELECT sequence_schema, sequence_name, current_value
FROM v_catalog.sequences;

Si la consulta devuelve una fila con un current_value numérico, la secuencia existe y está activa — el DDL que la referencia es válido y funcionará correctamente al insertar nuevas filas.

Ver dependencias entre tabla y secuencia

Para confirmar específicamente qué tabla(s) están usando una secuencia determinada (útil antes de eliminar o modificar una secuencia, para no romper nada):

SELECT *
FROM v_catalog.sequence_dependencies
WHERE sequence_name = 'seq_ejemplo';

Columnas IDENTITY vs. secuencias nombradas

Vale la pena distinguir dos mecanismos distintos que Vertica ofrece para autoincrementar valores:

  • Columnas IDENTITY — se definen directamente en el DDL de la tabla (id IDENTITY(1,1)) y Vertica crea automáticamente una secuencia interna asociada, visible también en v_catalog.sequences, pero gestionada implícitamente junto con la tabla.
  • Secuencias nombradas — creadas explícitamente con CREATE SEQUENCE, y luego referenciadas manualmente con nextval('esquema.nombre') en el DEFAULT de una o más columnas. Este es el caso descrito en este artículo.

La diferencia práctica más importante: una secuencia nombrada puede ser compartida entre varias tablas o columnas distintas si así se diseña, mientras que una columna IDENTITY está atada exclusivamente a la tabla donde se definió.

Comportamiento distribuido de las secuencias

Al ser Vertica un motor distribuido (MPP), las secuencias no funcionan exactamente igual que en un motor de un solo nodo: cada nodo del clúster mantiene su propia caché local de valores de secuencia durante una sesión, y las solicita de forma independiente conforme las va necesitando. Esto garantiza que todos los valores generados sean únicos, pero como consecuencia, los valores de nextval() pueden aparecer no consecutivos si distintos nodos están insertando datos en paralelo — es un comportamiento esperado y normal en Vertica, no un error.

Detalle adicional: simplificar expresiones de timestamp

Un ajuste menor mencionado durante la revisión del DDL — la expresión con cast explícito:

(statement_timestamp())::timestamp

Puede simplificarse, ya que statement_timestamp() ya retorna un tipo timestamp nativo, haciendo el cast redundante:

DEFAULT statement_timestamp()

Resumen del flujo de verificación

  1. Confirmar que la secuencia existe con SELECT * FROM v_catalog.sequences WHERE sequence_name = '...'.
  2. Si no existe, crearla explícitamente con CREATE SEQUENCE antes de referenciarla en cualquier DEFAULT nextval(...).
  3. Revisar v_catalog.sequence_dependencies antes de modificar o eliminar una secuencia en uso, para identificar todas las tablas que dependen de ella.
  4. Recordar que los valores pueden no ser consecutivos en un clúster con varios nodos activos — no es un bug, es el comportamiento distribuido esperado.

More posts