相关疑难解决方法(0)

在 Ubuntu 12.04 上使用 PG 9.1。

目前，我们在数据库上运行大量 UPDATE 语句最多需要 24 小时，它们的形式如下：

UPDATE table
SET field1 = constant1, field2 = constant2, ...
WHERE id = constid

（我们只是覆盖由 ID 标识的对象的字段。）这些值来自外部数据源（尚未在数据库中的表中）。

每个表都有几个索引，没有外键约束。直到最后都没有提交。

导入pg_dump整个数据库的一个需要 2 小时。这似乎是我们应该合理定位的基线。

除了生成以某种方式重建数据集以供 PostgreSQL 重新导入的自定义程序之外，我们是否可以做些什么来使批量 UPDATE 性能更接近导入的性能？（这是一个我们认为日志结构合并树处理得很好的领域，但我们想知道是否可以在 PostgreSQL 中做任何事情。）

一些想法：

• 删除所有非 ID 索引然后重建？
• 增加 checkpoint_segments，但这真的有助于维持长期吞吐量吗？
• 使用这里提到的技术？（将新数据加载为表，然后“合并”在新数据中找不到 ID 的旧数据）

基本上有很多事情要尝试，但我们不确定什么是最有效的，或者我们是否忽略了其他事情。我们将在接下来的几天里进行实验，但我们想我们也会在这里问。

我确实在表上有并发负载，但它是只读的。

我已经获得了我的 PostgreSQL 数据库的转储：

pg_dump -U user-name -d db-name -f dumpfile

然后我继续在另一个数据库中恢复：

psql X -U postgres  -d db-name-b -f dumpfile

我的问题是数据库包含引用约束、检查和触发器，其中一些（特别是检查）在恢复过程中失败，因为信息没有按照会导致这些检查得到遵守的顺序加载。例如，在表中插入一行可能与CHECK调用一个plpgsql函数相关联，该函数检查某个条件是否在某个其他不相关的表中成立。如果后者没有psql在前者之前加载，则会发生错误。

下面是一个 SSCCE，它产生了这样一个一旦转储pg_dump就无法恢复的数据库：

CREATE OR REPLACE FUNCTION fail_if_b_empty () RETURNS BOOLEAN AS $$
    SELECT EXISTS (SELECT 1 FROM b)
$$ LANGUAGE SQL;

CREATE TABLE IF NOT EXISTS a (
     i              INTEGER                    NOT NULL
);

INSERT INTO a(i) VALUES (0),(1);
CREATE TABLE IF NOT EXISTS b (
    i  INTEGER NOT NULL
);
INSERT INTO …

我有一个表，其架构如下：

create_table "questions_tags", :id => false, :force => true do |t|
        t.integer "question_id"
        t.integer "tag_id"
      end

      add_index "questions_tags", ["question_id"], :name => "index_questions_tags_on_question_id"
      add_index "questions_tags", ["tag_id"], :name => "index_questions_tags_on_tag_id"

我想删除重复的记录，即它们既具有相同的记录tag_id又question_id与另一条记录相同。

SQL 看起来像什么？