varchar 字段声明的大小对 PostgreSQL 有影响吗?

发布于 2024-07-26 01:14:13 字数 130 浏览 5 评论 0原文

从性能角度来看,VARCHAR(100)VARCHAR(500) 更好吗? 磁盘使用情况如何?

今天谈论的是 PostgreSQL,而不是历史上某个时期的某个数据库。

Is VARCHAR(100) any better than VARCHAR(500) from a performance point of view? What about disk usage?

Talking about PostgreSQL today, not some database some time in history.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

你在我安 2024-08-02 01:14:14

varchar(m)varchar(n) 之间没有区别。

http://archives.postgresql.org/pgsql-admin/2008-07/msg00073.php

varchar(n) 之间有区别text 不过,varchar(n) 有一个内置约束,必须进行检查,而且实际上速度有点慢。

http://archives.postgresql.org/pgsql-general/2009-04 /msg00945.php

There is no difference between varchar(m) and varchar(n)..

http://archives.postgresql.org/pgsql-admin/2008-07/msg00073.php

There is a difference between varchar(n) and text though, varchar(n) has a built in constraint which must be checked and is actually a little slower.

http://archives.postgresql.org/pgsql-general/2009-04/msg00945.php

墨落画卷 2024-08-02 01:14:14

TEXT /is/ 与 VARCHAR 相同,没有明确的长度,文本

“短期的存储要求
字符串(最多 126 字节)为 1 字节
加上实际的字符串,其中包括
的情况下的空间填充
特点。 较长的字符串有 4 个字节
开销而不是 1. 长字符串
被系统压缩了
自动地,所以物理
对磁盘的要求可能会更少。
非常长的值也存储在
背景表,这样他们就不会
干扰快速访问较短的内容
列值。 无论如何,
最长可能的字符串
可存储约1GB。”

指的是 VARCHAR 和 TEXT(因为 VARCHAR(n) 只是 TEXT 的有限版本)。人为地限制 VARCHARS 没有真正的存储或性能优势(开销基于实际长度)字符串的长度,而不是底层 varchar 的长度),除了可能与通配符和正则表达式的比较(但在这开始重要的级别,您可能应该考虑诸如 PostgreSQL 的全文索引支持之类的东西)。

TEXT /is/ the same as VARCHAR without an explicit length, the text

"The storage requirement for a short
string (up to 126 bytes) is 1 byte
plus the actual string, which includes
the space padding in the case of
character. Longer strings have 4 bytes
overhead instead of 1. Long strings
are compressed by the system
automatically, so the physical
requirement on disk might be less.
Very long values are also stored in
background tables so that they do not
interfere with rapid access to shorter
column values. In any case, the
longest possible character string that
can be stored is about 1 GB."

refers to both VARCHAR and TEXT (since VARCHAR(n) is just a limited version of TEXT). Limiting your VARCHARS artificially has no real storage or performance benefits (the overhead is based on the actual length of the string, not the length of the underlying varchar), except possibly for comparisons against wildcards and regexes (but at the level where that starts to matter, you should probably be looking at something like PostgreSQL's full-text indexing support).

最后的乘客 2024-08-02 01:14:13

它们是相同的。

来自 PostgreSQL 文档:

http://www.postgresql.org/docs/ 8.3/static/datatype-character.html

提示:没有任何性能
这三种类型之间的区别,
除了增加存储大小之外
使用空白填充类型,以及一些
额外的循环来检查长度
存储到长度受限的
柱子。 虽然字符(n)有
其他一些方面的性能优势
数据库系统,它没有这样的
PostgreSQL 的优势。 多数情况
情况文本或字符变化
应该使用它来代替。

这里他们讨论的是 char(n)、varchar(n) 和 text (= varchar(1G)) 之间的区别。 官方的说法是varchar(100)和text(非常大的varchar)之间没有区别。

They are identical.

From the PostgreSQL documentation:

http://www.postgresql.org/docs/8.3/static/datatype-character.html

Tip: There are no performance
differences between these three types,
apart from increased storage size when
using the blank-padded type, and a few
extra cycles to check the length when
storing into a length-constrained
column. While character(n) has
performance advantages in some other
database systems, it has no such
advantages in PostgreSQL. In most
situations text or character varying
should be used instead.

Here they are talking about the differences between char(n), varchar(n) and text (= varchar(1G)). The official story is that there is no difference between varchar(100) and text (very large varchar).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文