相关疑难解决方法(0)

假设我有一个包含字段A和的表B。我在A+上进行常规查询B，所以我在 上创建了一个复合索引(A,B)。A复合索引是否也会对查询进行全面优化？

此外，我在 上创建了一个索引A，但 Postgres 仍然只使用复合索引来查询A。如果前面的答案是肯定的，我想这并不重要，但是为什么它默认选择复合索引，如果单个A索引可用？

根据PostgreSQL 的文档，VARCHAR,VARCHAR(n)和之间没有性能差异TEXT。

我应该为名称或地址列添加任意长度限制吗？

编辑：不是欺骗：

• 当所有值都是 36 个字符时，使用 char 和 varchar 进行索引查找会明显更快吗

我知道这种CHAR类型是过去的遗物，我不仅对性能感兴趣，而且对其他优缺点感兴趣，例如 Erwin 在他惊人的回答中所述。

我们的系统写入了大量数据（一种大数据系统）。写入性能足以满足我们的需求，但读取性能真的太慢了​​。

我们所有表的主键（约束）结构都相似：

timestamp(Timestamp) ; index(smallint) ; key(integer).

一个表可以有数百万行，甚至数十亿行，而一个读请求通常是针对特定时间段（时间戳/索引）和标记的。查询返回大约 20 万行是很常见的。目前，我们每秒可以读取大约 15k 行，但我们需要快 10 倍。这是可能的，如果是，如何？

注意： PostgreSQL 是和我们的软件一起打包的，所以不同客户端的硬件是不一样的。

它是一个用于测试的虚拟机。VM 的主机是具有 24.0 GB RAM 的 Windows Server 2008 R2 x64。

服务器规范（虚拟机 VMWare）

Server 2008 R2 x64
2.00 GB of memory
Intel Xeon W3520 @ 2.67GHz (2 cores)

postgresql.conf 优化

shared_buffers = 512MB (default: 32MB)
effective_cache_size = 1024MB (default: 128MB)
checkpoint_segment = 32 (default: 3)
checkpoint_completion_target = 0.9 (default: 0.5)
default_statistics_target = 1000 (default: 100)
work_mem = 100MB (default: 1MB)
maintainance_work_mem = 256MB …

我们在 Postgres 中有一个 2.2 GB 的表，其中有 7,801,611 行。我们正在向它添加一个 uuid/guid 列，我想知道填充该列的最佳方法是什么（因为我们想NOT NULL向它添加约束）。

如果我正确理解 Postgres，更新在技术上是删除和插入，所以这基本上是重建整个 2.2 gb 表。我们还有一个奴隶在运行，所以我们不希望它落后。

有没有比编写一个随着时间慢慢填充它的脚本更好的方法？

我有一个旧模式（免责声明！），它使用基于哈希生成的 id 作为所有表的主键（有很多）。这种 id 的一个例子是：

922475bb-ad93-43ee-9487-d2671b886479

改变这种方法是不可能的，但是索引访问的性能很差。撇开这可能的无数原因不谈，我注意到有一件事似乎不太理想 - 尽管所有许多表中的所有 id 值的长度都正好是 36 个字符，但列类型是varchar(36)，而不是 char(36)。

将列类型更改为固定长度是否会char(36)提供任何显着的索引性能优势，除了每个索引页的条目数量增加很小等之外？

即在处理固定长度类型时 postgres 的执行速度是否比处理可变长度类型快得多？

请不要提及微小的存储节省 - 与对列进行更改所需的手术相比，这无关紧要。

我正在使用 PostgreSQL (9.4) 数据库在 Ruby on Rails 中开发应用程序。对于我的用例，表中的列将被非常频繁地查找，因为应用程序的重点是在模型上搜索非常具体的属性。

我目前正在决定是对列使用integer类型还是简单地使用典型的字符串类型（例如character varying(255)，这是 Rails 中的默认值），因为我不确定索引上的性能差异是什么。

这些列是 enums。对于它们可以拥有的可能值的数量，它们具有固定的大小。大多数枚举长度不超过 5，这意味着索引在应用程序的整个生命周期中或多或少是固定的；因此，整数和字符串索引在节点数上是相同的。

但是，将被索引的字符串可能有大约 20 个字符长，在内存中大约是整数的 5 倍（如果一个整数是 4 个字节，并且字符串是纯 ASCII 每个字符 1 个字节，那么这成立）。我不知道数据库引擎如何进行索引查找，但是如果它需要“扫描”字符串直到它完全匹配，那么本质上这意味着字符串查找将比整数查找慢 5 倍；整数查找匹配之前的“扫描”将是 4 个字节而不是 20 个。这就是我的想象：

查找值为（整数）4：

扫描………………………………………………………………………………………………………………………………………… 正在获取记录... |BYTE_1|BYTE_2|BYTE_3|BYTE_4|BYTE_5|BYTE_6|BYTE_7|BYTE_8|...|

查找值是（字符串）“some_val”（8 个字节）：

扫描................................................. …………………………………………………………………………………………………………………………………………………………………… 正在获取记录... |BYTE_1|BYTE_2|BYTE_3|BYTE_4|BYTE_5|BYTE_6|BYTE_7|BYTE_8|...|

我希望这是有道理的。基本上，因为整数占用更少的空间，它可以比它的字符串对应物更快地“匹配”。也许这是一个完全错误的猜测，但我不是专家，所以这就是我问你们的原因！我想我刚刚找到的这个答案似乎支持我的假设，但我想确定一下。

列中可能值的数量在使用任何一个时都不会改变，因此索引本身不会改变（除非我向枚举添加了一个新值）。在这种情况下，使用integeror会有性能差异varchar(255)，还是使用整数类型更有意义？

我问的原因是 Rails 的enum类型将整数映射到字符串键，但它们并不是面向用户的列。本质上，您无法验证枚举值是否有效，因为无效值会ArgumentError在运行任何验证之前导致。使用string类型将允许验证，但如果存在性能成本，我宁愿绕过验证问题。

VACUUM通常不会将磁盘空间返回给操作系统，除非在某些特殊情况下。
从文档：

VACUUM删除表和索引中的死行版本并标记可用空间以供将来重用的标准形式。但是，它不会将空间返回给操作系统，除非在表末尾的一个或多个页面完全空闲并且可以轻松获得排他表锁的特殊情况下。相比之下，VACUUM FULL通过编写一个没有死空间的完整新版本的表文件来主动压缩表。这最大限度地减少了表的大小，但可能需要很长时间。它还需要额外的磁盘空间用于表的新副本，直到操作完成。

问题是：如何实现这个数据库状态one or more pages at the end of a table become entirely free？这可以通过 完成VACUUM FULL，但我没有足够的空间来实现它。那么还有没有其他可能呢？

假设我们有一个包含四列(a,b,c,d)相同数据类型的表。

是否可以选择列中数据中的所有不同值并将它们作为单个列返回，或者我是否必须创建一个函数来实现这一点？

我想从Postgres 文档中询问这个片段关于varchar(n)类型的含义：

短字符串（最多 126 个字节）的存储要求是 1 个字节加上实际字符串，其中包括字符情况下的空格填充。较长的字符串有 4 个字节的开销而不是 1 个字节。

假设我有一个varchar(255)字段。现在，以下声明：

• 如果该字段包含 10 个字节的字符串，则开销为 1 个字节。因此该字符串将使用 11 个字节。
• 如果该字段使用 140 个字节保存字符串，则开销为 4 个字节。因此该字符串将使用 144 个字节。

上面的那些说法是真的吗？这里有人理解文档相同的方式，我不过这里有人指出的开销总是4个字节在这里？

我已将数据导入新数据库（大约 600m 行时间戳、整数、双精度）。然后我创建了一些索引并试图改变一些列（有一些空间不足的问题），数据库被清空了。

现在 pgAdmin III 告诉我“临时文件的大小”是 50G~+。

1. 这些临时文件是什么？这些像 SQL Server 事务日志吗？
2. 我怎样才能摆脱它们，似乎数据库比它应该大得多（数据库的总大小为 91 GB）

在Windows 2012 服务器上使用Posgres 9.4.1 。

数据库统计选项卡的屏幕截图：