正如文档中的“字符类型”所指出的，varchar(n)、char(n)和text都是以相同的方式存储的。唯一的区别是需要额外的循环来检查长度，如果给定了一个，如果需要填充char(n)，则需要额外的空间和时间。

然而，当您只需要存储单个字符时，使用特殊类型“char”会有轻微的性能优势(保留双引号-它们是类型名称的一部分)。您可以更快地访问字段，并且没有存储长度的开销。

我刚刚创建了一个包含1,000,000个从小写字母中随机选择的“字符”的表。查询频率分布(select count(*)， field…按字段分组)大约需要650毫秒，而使用文本字段的相同数据大约需要760毫秒。

Text和varchar有不同的隐式类型转换。我注意到的最大影响是对尾随空格的处理。例如……

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

返回真，假，真和不真，真，真，如你所料。

character varying(n)， varchar(n) -(两者相同)。值将被截断为n个字符而不引发错误。 character(n)， char(n) -(都是一样的)。固定长度，并将空白垫至长度结束。 文本-无限长度。

例子:

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

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

我们得到了结果:

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

没有区别，在引子里都是可变长度数组。

查看本文来自Depesz: http://www.depesz.com/index.php/2010/03/02/charx-vs-varcharx-vs-varchar-vs-text/

以下是几个亮点:

总结一下: Char (n)——在处理小于n的值时占用太多空间(将它们填充到n)，并且由于添加尾随会导致微妙的错误 空格，加上改变极限是有问题的 Varchar (n) -在活动环境中更改限制是有问题的(在更改表时需要排他锁) Varchar -就像文本一样 Text -对我来说是胜过(n)数据类型的赢家，因为它没有数据类型的问题，胜过varchar -因为它有独特的名称

本文进行了详细的测试，以证明所有4种数据类型的插入和选择的性能是相似的。它还详细介绍了在需要时限制长度的其他方法。基于函数的约束或域提供了立即增加长度约束的优势，并且基于减少字符串长度约束的情况很少，depesz得出结论，它们中的一个通常是长度限制的最佳选择。

(这个答案是Wiki，你可以编辑-请改正和改进!)

更新2016年基准(pg9.5+)

使用“纯SQL”基准测试(不需要任何外部脚本)

使用UTF8的任何string_generator 主要指标:

2.1. 插入

2.2. 选择比较和计数

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;

准备具体的测试(示例)

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

执行基本测试:

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

还有其他测试，

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;

．.． 并使用EXPLAIN ANALYZE。

2018年再次更新(pg10)

小小的编辑增加了2018年的结果，并加强了建议。

2016年和2018年的结果

我的结果，在许多机器和许多测试中，经过平均后:都是一样的(统计上小于标准偏差)。

建议

使用文本数据类型，避免旧的varchar(x)，因为有时它不是一个标准，例如在CREATE FUNCTION子句中varchar(x)≠varchar(y)。 用CREATE表中的CHECK子句表达限制(具有相同的varchar性能!)，例如CHECK(char_length(x)<=10)。在INSERT/UPDATE中可以忽略不计的性能损失，您还可以控制范围和字符串结构，例如CHECK(char_length(x)>5 and char_length(x)<=20 and x LIKE 'Hello%')

正如文档中的“字符类型”所指出的，varchar(n)、char(n)和text都是以相同的方式存储的。唯一的区别是需要额外的循环来检查长度，如果给定了一个，如果需要填充char(n)，则需要额外的空间和时间。

然而，当您只需要存储单个字符时，使用特殊类型“char”会有轻微的性能优势(保留双引号-它们是类型名称的一部分)。您可以更快地访问字段，并且没有存储长度的开销。

我刚刚创建了一个包含1,000,000个从小写字母中随机选择的“字符”的表。查询频率分布(select count(*)， field…按字段分组)大约需要650毫秒，而使用文本字段的相同数据大约需要760毫秒。