如果你只使用文本类型，在使用AWS数据库迁移服务时可能会遇到问题:

使用大对象(LOB)，但目标LOB列不能为空

由于大型对象(lob)的大小未知且有时较大，因此需要更多的处理 和资源比标准对象。以帮助调整包含 lob, AWS DMS提供以下选项

如果你在所有事情上都坚持使用PostgreSQL，那么你可能没问题。但如果你打算通过ODBC或DMS等外部工具与你的db交互，你应该考虑不要事事使用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

在PostgreSQL手册上

There is no performance difference among these three types, apart from increased storage space when using the blank-padded type, and a few extra CPU cycles to check the length when storing into a length-constrained column. While character(n) has performance advantages in some other database systems, there is no such advantage in PostgreSQL; in fact character(n) is usually the slowest of the three because of its additional storage costs. In most situations text or character varying should be used instead.

我通常使用文本

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

(这个答案是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%')

有些OT:如果你使用Rails，网页的标准格式可能会有所不同。对于数据输入表单，文本框是可滚动的，但是字符变化(Rails字符串)框是一行的。显示视图根据需要而定。

如果你只使用文本类型，在使用AWS数据库迁移服务时可能会遇到问题:

使用大对象(LOB)，但目标LOB列不能为空

由于大型对象(lob)的大小未知且有时较大，因此需要更多的处理 和资源比标准对象。以帮助调整包含 lob, AWS DMS提供以下选项

如果你在所有事情上都坚持使用PostgreSQL，那么你可能没问题。但如果你打算通过ODBC或DMS等外部工具与你的db交互，你应该考虑不要事事使用TEXT。