运行时：
TRUNCATE TABLE YYYYY RESTART IDENTITY
我看到此错误消息：
ERROR: cannot truncate a table referenced in a foreign key constraint
DETAIL: Table "XXXXX" references "YYYYY".
HINT: Truncate table "XXXXX" at the same time, or use TRUNCATE ... CASCADE.
在以下两个建议中HINT：
使用TRUNCATE ... CASCADE是有意义的，并且有效，但不太明确，因为必须检查YYYYY以查看级联的去向。这让我想尝试另一种选择：
Truncate table "XXXXX" at the same time，但我的问题：
截断表是什么意思at the same time？
我尝试添加 a TRUNCATE XXXXX...（并将它们都包装在BEGIN/中COMMIT），但这会产生相同的错误。
我有一张大约有一百万行的表。
它正在生产中使用，我运行了一个UPDATE覆盖约 95% 的行。
五个小时后，我取消了请求，因为它花了很长时间。
该表有一个自动递增的 ID 列，因此我尝试将WHERE查询条件扩展为包含id BETWEEN 1 AND 500.
此更新在大约两秒钟内完成。然后我手动迭代了id500 个批次，例如BETWEEN 500 AND 1000，然后BETWEEN 1000 AND 1500。
按照这个速度，将需要 2000 批 500 来更新整个表。
以 2 秒的速度更新 2000 个批次仅需要一个多小时。
我的问题是：
我有一个表t，有一个名为 的列json，类型为JSON。在 JSON 中有一个自然键：
> SELECT json->'id' AS id FROM t LIMIT 1;
id
-----------------------------
" 63631ff3809de7a17398602f"
我可以创建一个UNIQUE INDEXon id，因此：
> CREATE UNIQUE INDEX t_id ON t((json->>'id'));
CREATE INDEX
我想将其添加为table_constraint_using_index，但两者都失败PRIMARY KEY：
> ALTER TABLE t ADD CONSTRAINT t_pkey PRIMARY KEY USING INDEX t_id;
ERROR: index "t_id" contains expressions
LINE 1: ALTER TABLE t ADD CONSTRAINT t_pkey
^
DETAIL: Cannot create a primary key or unique constraint using such an index.
和UNIQUE：
> ALTER TABLE t ADD CONSTRAINT t_unique_id UNIQUE USING INDEX t_id;
ERROR: index "t_id" contains expressions
LINE 1: ALTER TABLE t ADD CONSTRAINT t_unique_id...
^
DETAIL: Cannot create a primary key or unique constraint using such an index.
我应该能够添加这样的约束吗？
我们可以为 Postgres 中的字段创建部分索引。
我正在考虑使用它来阻止archived位于以下索引中的行created_at field：
首先我们创建索引：
test=# CREATE INDEX idx_my_table_created_at ON my_table(created_at) WHERE NOT(archived);
我们插入两行，一行进入，另一行idx_my_table_created_at不进入：
id | created_at | archived
----+----------------------------+----------
2 | 2012-10-12 17:39:17.28511 | t
1 | 2012-10-12 17:38:55.531278 | f
现在我们UPDATE有一行目前在索引中，因此它不应该在索引中：
test=# UPDATE my_table SET archived = true WHERE id = 1;
我的问题：id = 1还在idx_my_table_created_at吗？
这个问题是从我问过的一个问题的答案开始的，这个问题是关于如何处理一旦过时就不会被查询的行，因此archived。
我很难找到关于如何在 PostgreSQL 中缓存索引的“普通”解释，所以我想对任何或所有这些假设进行现实检查：
buffer cache行位于相同的缓存（？）中，因此索引使用的缓存空间对行不可用。在进行此操作之前，我想明确一点，使用部分索引会产生两个优点：
我们在 PostgreSQL 数据库中有一个表，该表每天以数百万行的数量级增长。
每行包括：
ID
Foreign user ID
Date and time
Other data
日期和时间与 并不严格单调ID，但它们很接近。
查询此表时，我们只对获取给定外国用户 ID 的行感兴趣，这些行的日期和时间在过去两周内。两周前的行将永远不会被查询，但是我们希望保留它们以供存档。
鉴于这个特殊用例：