标签: postgresql

我注意到查询子句中的USING构造（而不是ON）可能会在某些情况下引入优化障碍。FROMSELECT

我的意思是这个关键词：

选择 *
从一个
加入 b使用(a_id)

只是在更复杂的情况下。

上下文：this comment to this question。

我用这个了很多，从来没有发现过这么远。我会对展示效果的测试用例或任何指向更多信息的链接非常感兴趣。我的搜索努力是空的。

完美的答案将是一个测试用例，USING (a_id)与替代 join 子句相比，它的性能较差ON a.a_id = b.a_id——如果这真的可以发生的话。

我有一张桌子占用了我们服务器上接近 90% 的高清空间。我决定删除几列以释放空间。但我需要将空间归还给操作系统。但是，问题是我不确定如果我运行 VACUUM FULL 并且没有足够的可用空间来制作表的副本会发生什么。

我知道不应使用 VACUUM FULL，但我认为这是这种情况下的最佳选择。

任何想法，将不胜感激。

我正在使用 PostgreSQL 9.0.6

我在 Ubuntu 上使用 PostgreSQL 9.1。VACUUM ANALYZE仍然推荐预定，还是 autovacuum 足以满足所有需求？

如果答案是“视情况而定”，那么：

• 我有一个较大的数据库（30 GiB 压缩转储大小，200 GiB 数据目录）
• 我对数据库做 ETL，每周导入接近 300 万行
• 变化最频繁的表全部继承自一个主表，主表中没有数据（数据按周分区）
• 我创建每小时汇总，并从那里创建每日、每周和每月报告

我问是因为预定的时间VACUUM ANALYZE会影响我的报告。它运行了 5 个多小时，本周我不得不杀死它两次，因为它影响了常规的数据库导入。check_postgres不会报告数据库有任何显着膨胀，所以这不是真正的问题。

从文档中，autovacuum 也应该处理事务 ID 环绕。问题是：我还需要一个VACUUM ANALYZE吗？

我正在使用 PostgreSQL 9.1 并且我有一个带有login列的用户表。

登录名区分大小写，例如 Bob、MikE、john。我想将所有这些记录转换为小写。我怎样才能做到这一点？

这很简单，但我对 PG 所做的（v9.0）感到困惑。我们从一个简单的表开始：

CREATE TABLE test (id INT PRIMARY KEY);

和几行：

INSERT INTO TEST VALUES (1);
INSERT INTO TEST VALUES (2);

使用我最喜欢的 JDBC 查询工具 (ExecuteQuery)，我将两个会话窗口连接到该表所在的数据库。它们都是事务性的（即 auto-commit=false）。我们称它们为 S1 和 S2。

每个相同的代码位：

1:DELETE FROM test WHERE id=1;
2:INSERT INTO test VALUES (1);
3:COMMIT;

现在，以慢动作运行它，在窗口中一次执行一个。

S1-1 runs (1 row deleted)
S2-1 runs (but is blocked since S1 has a write lock)
S1-2 runs (1 row inserted)
S1-3 runs, releasing the write lock
S2-1 runs, now that it can get the lock. But reports …

今天早上我一直在尝试连接 Windows 7 Professional 桌面上的 PostgreSQL 数据库。

默认值是“postgres”，但果然我忘记了最初安装时使用的密码。

我用谷歌搜索并找到了一篇与重置密码相关的帖子。我按照步骤操作，但最终结果与帖子中提到的有点不同。我用了-

net user postgres postgres

为我的数据库重置密码，但我收到的不是成功消息：

“发生系统错误 5。访问被拒绝。”

系统错误。如何避免此错误并重置密码？

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

922475bb-ad93-43ee-9487-d2671b886479

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

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

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

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

我想按日期范围对 100 万行以上的表进行分区。这通常是如何在不需要大量停机时间或冒丢失数据的风险的情况下完成的？以下是我正在考虑的策略，但欢迎提出建议：

1. 现有的表是主表，子表是从它继承而来的。随着时间的推移，将数据从主表移动到子表，但会有一段时间，其中一些数据在主表中，一些在子表中。

2. 创建一个新的主表和子表。在子表中创建现有表中的数据副本（因此数据将驻留在两个位置）。一旦子表拥有最新数据，更改所有插入以指向新的主表并删除现有表。

我有一个与性能相关的问题。假设我有一个名为 Michael 的用户。进行以下查询：

UPDATE users
SET first_name = 'Michael'
WHERE users.id = 123

查询是否会实际执行更新，即使它被更新为相同的值？如果是这样，我该如何防止它发生？

我正在使用 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类型将允许验证，但如果存在性能成本，我宁愿绕过验证问题。