PostgreSQL: diferencia entre texto y varchar (variación de caracteres)

¿Cuál es la diferencia entre el texttipo de datos y los tipos de datos character varying( varchar)?

De acuerdo a la documentación

Si se usa la variación de caracteres sin un especificador de longitud, el tipo acepta cadenas de cualquier tamaño. Este último es una extensión PostgreSQL.

y

Además, PostgreSQL proporciona el tipo de texto, que almacena cadenas de cualquier longitud. Aunque el texto de tipo no está en el estándar SQL, otros sistemas de administración de bases de datos SQL también lo tienen.

Entonces, ¿cuál es la diferencia?

No hay diferencia, debajo del capó es todo varlena( matriz de longitud variable ).

Consulte este artículo de Depesz: http://www.depesz.com/index.php/2010/03/02/charx-vs-varcharx-vs-varchar-vs-text/

Un par de puntos destacados:

Para resumir todo esto:

• char (n): ocupa demasiado espacio cuando se manejan valores más cortos que n(los rellena n) y puede generar errores sutiles debido a la adición de espacios finales, además es problemático cambiar el límite
• varchar (n): es problemático cambiar el límite en el entorno en vivo (requiere un bloqueo exclusivo mientras se modifica la tabla)
• varchar - al igual que el texto
• texto - para mí un ganador - sobre (n) tipos de datos porque carece de sus problemas, y sobre varchar - porque tiene un nombre distinto

El artículo realiza pruebas detalladas para mostrar que el rendimiento de las inserciones y las selecciones para los 4 tipos de datos son similares. También toma una mirada detallada a formas alternativas de restringir la longitud cuando sea necesario. Las restricciones o dominios basados ​​en funciones proporcionan la ventaja de un aumento instantáneo de la restricción de longitud, y sobre la base de que es poco frecuente reducir una restricción de longitud de cadena, depesz concluye que una de ellas suele ser la mejor opción para un límite de longitud.

Como " conjuntos de caracteres " en los puntos de documentación a cabo, varchar(n), char(n), y textse almacenan de la misma manera. La única diferencia es que se necesitan ciclos adicionales para verificar la longitud, si se da uno, y el espacio y el tiempo adicionales necesarios si se necesita relleno char(n).

Sin embargo, cuando solo necesita almacenar un solo carácter, existe una ligera ventaja de rendimiento al usar el tipo especial "char"(mantenga las comillas dobles, son parte del nombre del tipo). Obtiene un acceso más rápido al campo y no hay gastos generales para almacenar la longitud.

Acabo de hacer una tabla de 1,000,000 "char"elegidos al azar del alfabeto en minúsculas. Una consulta para obtener una distribución de frecuencia ( select count(*), field ... group by field) tarda aproximadamente 650 milisegundos, frente a aproximadamente 760 en los mismos datos utilizando un textcampo.

ACTUALIZACIÓN DE BANCOS PARA 2016 (pg9.5 +)

Y utilizando puntos de referencia "SQL puro" (sin ningún script externo)

1. use cualquier string_generator con UTF8

2. principales puntos de referencia:

   2.1. INSERTAR

   2.2. SELECCIONE comparando y contando

CREATE FUNCTION string_generator(int DEFAULT 20,int DEFAULT 10) RETURNS text AS $f$
  SELECT array_to_string( array_agg(
    substring(md5(random()::text),1,$1)||chr( 9824 + (random()*10)::int )
  ), ' ' ) as s
  FROM generate_series(1, $2) i(x);
$f$ LANGUAGE SQL IMMUTABLE;

Preparar prueba específica (ejemplos)

DROP TABLE IF EXISTS test;
-- CREATE TABLE test ( f varchar(500));
-- CREATE TABLE test ( f text); 
CREATE TABLE test ( f text  CHECK(char_length(f)<=500) );

Realizar una prueba básica:

INSERT INTO test  
   SELECT string_generator(20+(random()*(i%11))::int)
   FROM generate_series(1, 99000) t(i);

Y otras pruebas,

CREATE INDEX q on test (f);

SELECT count(*) FROM (
  SELECT substring(f,1,1) || f FROM test WHERE f<'a0' ORDER BY 1 LIMIT 80000
) t;

... y uso EXPLAIN ANALYZE.

ACTUALIZADO DE NUEVO 2018 (pg10)

pequeña edición para agregar los resultados de 2018 y reforzar las recomendaciones.

Resultados en 2016 y 2018

Mis resultados, después de la media, en muchas máquinas y muchas pruebas: todo lo mismo
(estadísticamente menos desviación estándar que el estándar).

Recomendación

• Utilice el texttipo de datos,
  evite los antiguos varchar(x)porque a veces no es un estándar, por ejemplo, en las CREATE FUNCTIONcláusulas varchar(x)≠varchar(y) .

• límites expresos (¡con el mismo varcharrendimiento!) con CHECKcláusula en el CREATE TABLE
  ej CHECK(char_length(x)<=10).
  Con una pérdida insignificante de rendimiento en INSERT / UPDATE, también puede controlar los rangos y la estructura de la cadena,
  por ejemploCHECK(char_length(x)>5 AND char_length(x)<=20 AND x LIKE 'Hello%')

En el manual de PostgreSQL

No hay diferencia de rendimiento entre estos tres tipos, aparte de un mayor espacio de almacenamiento cuando se usa el tipo de relleno en blanco, y algunos ciclos de CPU adicionales para verificar la longitud cuando se almacena en una columna de longitud limitada. Si bien el carácter (n) tiene ventajas de rendimiento en algunos otros sistemas de bases de datos, no existe tal ventaja en PostgreSQL; de hecho, el carácter (n) suele ser el más lento de los tres debido a sus costos de almacenamiento adicionales. En la mayoría de las situaciones, se debe usar texto o variación de caracteres.

Usualmente uso texto

Referencias: http://www.postgresql.org/docs/current/static/datatype-character.html

En mi opinión, varchar(n)tiene sus propias ventajas. Sí, todos usan el mismo tipo subyacente y todo eso. Pero, debe señalarse que los índices en PostgreSQL tienen su límite de tamaño de 2712 bytes por fila.

TL; DR: si usa el texttipo de letra sin restricción y tiene índices en estas columnas, es muy posible que alcance este límite para algunas de sus columnas y obtenga un error cuando intente insertar datos, pero con el uso varchar(n)puede evitarlo.

Algunos detalles más: El problema aquí es que PostgreSQL no da ninguna excepción al crear índices para el texttipo o varchar(n)donde nes mayor que 2712. Sin embargo, dará error cuando se intente insertar un registro con un tamaño comprimido mayor que 2712. Significa que puede insertar 100,000 caracteres de cadena que está compuesta por caracteres repetitivos fácilmente porque se comprimirá muy por debajo de 2712, pero es posible que no pueda insertar alguna cadena con 4000 caracteres porque el tamaño comprimido es mayor de 2712 bytes. Si usa varchar(n)where nno es mucho mayor que 2712, estará a salvo de estos errores.

text y varchar tienen diferentes conversiones de tipo implícito. El mayor impacto que he notado es el manejo de espacios finales. Por ejemplo ...

select ' '::char = ' '::varchar, ' '::char = ' '::text, ' '::varchar = ' '::text

regresa true, false, truey no true, true, truecomo es de esperar.

Algo OT: si está utilizando Rails, el formato estándar de las páginas web puede ser diferente. Para los formularios de entrada de datos, los textcuadros son desplazables, pero los cuadros character varying(Rails string) son de una línea. Mostrar vistas son tan largas como sea necesario.

Una buena explicación de http://www.sqlines.com/postgresql/datatypes/text :

La única diferencia entre TEXT y VARCHAR (n) es que puede limitar la longitud máxima de una columna VARCHAR, por ejemplo, VARCHAR (255) no permite insertar una cadena de más de 255 caracteres.

Tanto TEXT como VARCHAR tienen el límite superior a 1 Gb, y no hay diferencia de rendimiento entre ellos (de acuerdo con la documentación de PostgreSQL).

character varying(n), varchar(n)- (Ambos lo mismo). el valor se truncará en n caracteres sin generar un error.

character(n), char(n)- (Ambos lo mismo). de longitud fija y se rellenará con espacios en blanco hasta el final de la longitud.

text- Longitud ilimitada.

Ejemplo:

Table test:
   a character(7)
   b varchar(7)

insert "ok    " to a
insert "ok    " to b

Obtenemos los resultados:

a        | (a)char_length | b     | (b)char_length
----------+----------------+-------+----------------
"ok     "| 7              | "ok"  | 2