关于char，varchar与text平时没有太在意，一般来说，可能现在大家都是用varchar。但是当要存储的内容比较大时，究竟是选择varchar还是text呢？不知道。。。。。。 于是去查阅了一些资料，顺便将这三种类型做个比较： （1）char: char不用多说了，它是定长格式的，但是长度范围是0~255. 当你想要储存一个长度不足255的字符时，mysql会用空格来填充剩下的字符。因此在读取数据时，char类型的数据要进行处理，把后面的空格去除。 （2）varchar: 关于varchar，有的说最大长度是255，也有的说是65535，查阅很多资料后发现是这样的：varchar类型在5.0.3以下的版本中的最大长度限制为255，而在5.0.3及以上的版本中，varchar数据类型的长度支持到了65535，也就是说可以存放65532个字节（注意是字节而不是字符！！！）的数据（起始位和结束位占去了3个字节），也就是说，在5.0.3以下版本中需要使用固定的TEXT或BLOB格式存放的数据可以在高版本中使用可变长的varchar来存放，这样就能有效的减少数据库文件的大小。 （3）text:与char和varchar不同的是，text不可以有默认值，其最大长度是2的16次方-1 总结起来，有几点： 经常变化的字段用varchar 知道固定长度的用char 尽量用varchar 超过255字符的只能用varchar或者text 能用varchar的地方不用text
成都创新互联公司坚持“要么做到，要么别承诺”的工作理念，服务领域包括：成都网站建设、成都做网站、企业官网、英文网站、手机端网站、网站推广等服务，满足客户于互联网时代的达孜网站设计、移动媒体设计的需求，帮助企业找到有效的互联网解决方案。努力成为您成熟可靠的网络建设合作伙伴！
PostgreSQL命令 EXPLAIN ANALYZE 是日常工作中了解和优化SQL查询过程所用到的最强大工具，后接如 SELECT ... ， UPDATE ... 或者 DELETE ... 等SQL语句，命令执行后并不返回数据，而是输出查询计划，详细说明规划器通过何种方式来执行给定的SQL语句。
下面是从 Postgres Using EXPLAIN 提取的查询：
它生成的查询计划：
Postgres构建了一个规划节点的树结构，以表示所采取的不同操作，其中root根和每个 - 指向其中一个操作。在某些情况下， EXPLAIN ANALYZE 会提供除执行时间和行数之外的额外执行统计信息，例如上面例子中的 Sort 及 Hash 。除第一个没有 - 的行之外的任何行都是诸如此类的信息，因此查询的结构是：
每个树分支代表子动作，从里到外以确定哪个是“第一个”发生（尽管同一级别的节点顺序可能不同）。
在 tenk_unique1 索引上执行的第一个操作是 Bitmap Index Scan ：
这对应于SQL WHERE t1.unique1 100 。Postgres查找与条件 unique1 100 匹配的行位置。此处不会返回行数据本身。成本估算 (cost=0.00..5.04 rows=101 width=0) 意味着Postgres预期将“花费” 任意计算单位的 5.04 来找到这些行。0.00是此节点开始工作的成本（在这种情况下，即为查询的启动时间）。 rows 是此索引扫描将返回的预估行数， width 是这些返回行的预估大小（以字节为单位）（0是因为这里只关心位置，而不是行数据的内容）。
因为使用了 ANALYZE 选项运行 EXPLAIN ，所以查询被实际执行并捕获了计时信息。 (actual time=0.049..0.049 rows=100 loops=1) 表示索引扫描执行了1次（ loops 值），结果返回了100行，实际时间是0 ..如果节点执行了多次，实际时间是每次迭代的平均值，可以将该值乘以循环次数以获取实际时间。基于成本的最小/最大时间的概念，范围值也可能会有所不同。通过这些值，我们可以为该查询生成一个成本比率，每个成本单位为0.049ms / 5.04单位≈0.01ms/单位。
索引扫描的结果将传递给 Bitmap Heap Scan 操作。在此节点中，Postgres将获取别名为t1的tenk1表中行的位置，根据 unique1 100 条件筛选并获取行。
当乘以之前计算的0.01值时，我们可以得到成本预期的大概时间（229.20 - 5.07）*0.01≈2.24ms，同时每行实际时间为除以4后的结果：0.526ms。这可能是因为成本估算是取的上限而不是取所有需读取的行，也或者因为Recheck条件总是生效。
和表顺序读取行（a Seq Scan ）相比， Bitmap Index Scan 和 Bitmap Heap Scan 关联操作成本要昂贵得多，但是因为在这种情况下只需要访问相对较少的行，所以关联操作最终会变得更快。通过在获取行之前将行按照物理顺序排序来进一步加速，这会将单独获取的成本降到最低。节点名称中的“Bitmap”完成了排序操作。
表扫描的结果（tenk1表中满足 unique1 100 条件的那些行）将在读取时被插入到内存的哈希表中。正如我们从成本中看到的那样，这根本不需要时间。
哈希节点包括散列桶(hash buckets)和批次数(batches)相关的信息，以及内存使用峰值情况。如果批次 1，则还会包括未显示的磁盘使用信息。内存占用在100行* 244字节= 24.4 kB时是有意义的，它非常接近28kB，我们假定这是哈希键本身所占用的内存。
接下来，Postgres从别名为t2的tenk2表读取所有的10000行，并根据tenk1表行的Hash检查它们。散列连接意味着将一个表的行输入到内存中的散列（先前的操作中已构建），之后扫描另一个表的行，并根据散列表探测其值以进行匹配。在第二行可以看到“匹配”的条件， Hash Cond: (t2.unique2 = t1.unique2) 。请注意，因为查询是从tenk1和tenk2中选择所有值，所以在散列连接期间每行的宽度加倍。
现在已经收集了满足条件的所有行，可以对结果集进行排序 Sort Key: t1.fivethous 。
Sort节点包含排序算法 quicksort 相关的信息 ，排序是在内存中还是在磁盘上完成（这将极大地影响速度），以及排序所需的内存/磁盘空间量。
熟悉如何解读查询计划会非常有助于优化查询。例如，Seq Scan节点通常表示添加索引的必要性，读取速度可能要快得多。
翻译并编辑，原文出处：
一个bigint它占用了八个字节的存储空间，可以精确的表示从-2^63到2^63-1(即从-9，223，372，036，854，775，808到 9，223，372，036，854，775，807)之间的整数。所以恩，不是说一个数字，而是从-2^63到2^63-1都可以.
varchar 是按字节来存储，如 varchar(10),会占用11个字节，其中10个是用来定义字符，还有一个字节是用来存储列的长度
PostgreSQL二进制数据类型bytea保存2G数据ADO、ODBC等接口通带参数化插入SQL语句传二进制
某些接口、SQL语句进行参数绑定或者某些语言没二进制类型或者接口兼容等原传二进制数据
碰种情况必须客户端二进制转化定规则字符序列插入语句显示转换cast('字符序列' as bytea).
二进制转化字符序列规则：
析每字节其ASCII值031127255或39、92请字节转化3位八进制字符串前面加2反斜杠chr(39)表示//047. 其ascii值显示字符变全部转化八进制整字符串太浪费空间
二进制序列 chr(0)+'a'+'b'+chr(233)+chr(25)+'c'转化字符序列：
//000ab//351//031c
传候再显示转换 insert into table1 (aa) values (cast('//000ab//351//031c' as bytea))
二进制数据太传,用||连接符连接起,:
insert into table1 (id,aa) values (1,cast('序列1' as bytea))
update table1 set aa=aa||cast('序列2' as bytea) where id=1
