CHARe VARCHARsão implementados exatamente da mesma forma no Postgres (e Oracle). Não há diferença na velocidade ao usar esses tipos de dados.

No entanto, há uma diferença que pode fazer a diferença no desempenho: uma charcoluna é sempre preenchida com o comprimento definido. Portanto, se você definir uma coluna como char(100)e uma como, varchar(100)mas armazenar apenas 10 caracteres em cada uma, a char(100)coluna usará 100 caracteres para cada valor (os 10 caracteres que você armazenou, mais 90 espaços), enquanto a varcharcoluna armazena apenas 10 caracteres.

Comparar 100 caracteres com 100 caracteres será mais lento do que comparar 10 caracteres com 10 caracteres - embora eu duvide que você possa realmente medir essa diferença em uma consulta SQL.

Se você declarar ambos com o comprimento de 10 caracteres e sempre armazenar exatamente 10 caracteres neles, não haverá absolutamente nenhuma diferença (isso é verdade para Oracle e Postgres)

Portanto, a única diferença é o preenchimento que é feito para o chartipo de dados.

Lembre-se também de que geralmente há uma diferença muito grande entre um CHAR e um VARCHAR ao fazer comparações de índice

A citação acima só é verdadeira se (e somente se) a charcoluna for definida muito larga (ou seja, você está desperdiçando espaço devido ao preenchimento). Se o comprimento da charcoluna é sempre usado completamente (portanto, não ocorre preenchimento), a citação acima está errada (pelo menos para Postgres e Oracle)

Do meu ponto de vista, o chartipo de dados realmente não tem nenhum uso de palavra real. Basta usar varchar(ou textno Postgres) e esquecer que charexiste.

Concordo com tudo o que foi dito por a_horse_with_no_name e geralmente concordo com o conselho de comentário de Erwin:

Não, char é inferior (e desatualizado). text e varchar executam (quase) o mesmo.

Metadados

Com uma pequena exceção, a única vez que uso char()é quando quero que os metadados digam que isso DEVE ter caracteres x. Embora eu saiba que char()só reclama se a entrada estiver acima do limite, frequentemente protejo contra underruns em uma CHECKrestrição. Por exemplo,

CREATE TABLE foo (
  x char(10) CHECK ( length(x) = 10 )
);
INSERT INTO foo VALUES (repeat('x', 9));

Faço isso por alguns motivos,

1. char(x)às vezes é inferido com carregadores de esquema como sendo uma coluna de largura fixa. Isso pode fazer a diferença em uma linguagem otimizada para strings de largura fixa.
2. Estabelece uma convenção que faz sentido e é facilmente aplicada. Posso escrever um carregador de esquema em uma linguagem para gerar código a partir dessa convenção.

Preciso de um exemplo de onde posso fazer isso,

1. Abreviaturas de estado de duas letras, mas como essa lista pode ser enumerada, normalmente faço isso com um ENUM.
2. Números de identificação do veículo
3. Números de modelo (de tamanho fixo)

Sobre erros

Observe que algumas pessoas podem se sentir desconfortáveis ​​com a incongruência das mensagens de erro em ambos os lados do limite, mas isso não me incomoda

test=# INSERT INTO foo VALUES (repeat('x', 9));
ERROR:  new row for relation "foo" violates check constraint "foo_x_check"
DETAIL:  Failing row contains (xxxxxxxxx ).
test=# INSERT INTO foo VALUES (repeat('x', 11));
ERROR:  value too long for type character(10)

Contraste comvarchar

Além disso, acho que a sugestão acima se encaixa muito bem com uma convenção de quase sempre usartext . Você pergunta sobre varchar(n)também. Eu nunca uso isso . Pelo menos, não me lembro da última vez que usei varchar(n).

• Se uma especificação tiver um campo de largura estática em que confio, uso char(n),
• Caso contrário, eu uso textqual é efetivamente varchar(sem limite)

Se eu encontrasse uma especificação que tivesse chaves de texto de comprimento variável que fossem significativas e que eu confiasse para ter um comprimento máximo constante, eu também usaria varchar(n). No entanto, não consigo pensar em nada que se encaixe nesses critérios.

Notas Adicionais

• charaqui não deve ser confundido com"char" o que é um tipo de um byte e tem desempenho sólido e benefícios de economia de espaço.

Perguntas e respostas relacionadas:

• A pesquisa de índice seria visivelmente mais rápida com char vs varchar quando todos os valores são 36 caracteres
• Qual é a sobrecarga para varchar(n)?

Postgresql

sales_reporting_db=# create table x (y char(2));
CREATE TABLE
sales_reporting_db=# insert into x values ('Y');
INSERT 0 1
sales_reporting_db=# select '*' || y || '*' from x;
 ?column? 
----------
 *Y*

Oráculo

SQL> create table x ( y char(2));

Table created.

SQL> insert into x values ('Y');

1 row created.

SQL> select '*' || y || '*' from x;

'*'|
----
*Y *

O Postgresql não preencheu com espaços.

Achei isso mais útil e uma explicação rápida de 3 linhas:

De CHAR(n) vs VARCHAR(N) vs texto no Postgres

• Se você deseja armazenar algum texto com um comprimento desconhecido, use o TEXTtipo de dados.
• Se você deseja armazenar algum texto com comprimento desconhecido, mas sabe o comprimento máximo, use VARCHAR(n).
• Se você deseja armazenar algum texto com um comprimento exato conhecido, use CHAR(N).