¿VARCHAR (100) es mejor que VARCHAR (500) desde el punto de vista del rendimiento? ¿Qué pasa con el uso del disco?¿El tamaño declarado de un campo varchar tiene algún impacto en PostgreSQL?
Hablando de PostgreSQL hoy, no de alguna base de datos en algún momento de la historia.
Son idénticos.
De la documentación de PostgreSQL:
http://www.postgresql.org/docs/8.3/static/datatype-character.html
Consejo: No hay rendimiento diferencias entre estos tres tipos, aparte del aumento de tamaño de almacenamiento cuando utilizando el tipo rellenada con blancos, y una pocos ciclos extra 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 base de datos , no tiene tales ventajas en PostgreSQL. En la mayoría de las situaciones se debe usar texto o caracteres que varíen en su lugar.
Aquí están hablando de las diferencias entre char (n), varchar (n) y texto (= varchar (1G)). La historia oficial es que no hay diferencia entre varchar (100) y el texto (varchar muy grande).
TEXTO/es/lo mismo que VARCHAR sin una longitud explícita, el texto
"El requisito de almacenamiento durante un corto cadena (hasta 126 bytes) es de 1 byte más la cadena real, la cual incluye el relleno de espacio en el caso de carácter. cuerdas más largas tienen 4 bytes sobrecarga en lugar de 1. las cadenas largas son comprimidos por el sistema de forma automática, por lo que la física requisito en el disco podría ser menos. valores son muy largas también sto rojo en tablas de fondo para que no interfieran con el acceso rápido a valores de columna más cortos. En cualquier caso, el más larga cadena de caracteres posible que se puede almacenar es de 1 GB."
se refiere tanto a VARCHAR y TEXT (desde VARCHAR (n) es simplemente una versión limitada de texto). Limitar su VARCHARS artificialmente no tiene beneficios reales de almacenamiento o rendimiento (la sobrecarga se basa en la longitud real de la cadena, no la longitud de la varchar subyacente), excepto posiblemente para comparaciones contra comodines y expresiones regulares (pero en el nivel donde eso empieza a importar, probablemente debería estar mirando algo así como el soporte de indexación de texto completo de PostgreSQL).
No hay diferencia entre varchar(m) y varchar(n) ..
http://archives.postgresql.org/pgsql-admin/2008-07/msg00073.php
Hay una diferencia entre varchar(n) y text embargo, varchar(n) ha construido en un obstáculo que debe ser comprobado y es en realidad un poco más lento.
http://archives.postgresql.org/pgsql-general/2009-04/msg00945.php
Estoy hablando de VARCHAR (m) vs VARCHAR (n), no se trata de VARCHAR vs CHAR, que es lo que está señalando. – ibz
Verifique nuevamente. Se refieren a que los TRES son idénticos. Es decir. el rendimiento de varchar (n) es el mismo que el texto, que es varchar (LOTES). La única diferencia entre los TRES tipos es el relleno y la restricción de longitud. Tampoco se aplican entre varchar (100) y varchar (500), por lo que dicen que son iguales. –
Sí, mencionan los tres, pero solo insisten en dos. De hecho, hice esta pregunta en SO porque no estaba contento con ese párrafo en particular en el documento y estaba buscando una explicación más perspicaz. Y no, TEXT es * no * lo mismo que VARCHAR (LOTES). TEXTO se almacena fuera de la fila. Al menos AFAIK. – ibz