我在 Ubuntu 上使用 PostgreSQL 9.1。VACUUM ANALYZE仍然推荐预定，还是 autovacuum 足以满足所有需求？
如果答案是“视情况而定”，那么：
我问是因为预定的时间VACUUM ANALYZE会影响我的报告。它运行了 5 个多小时，本周我不得不杀死它两次，因为它影响了常规的数据库导入。check_postgres不会报告数据库有任何显着膨胀，所以这不是真正的问题。
从文档中，autovacuum 也应该处理事务 ID 环绕。问题是：我还需要一个VACUUM ANALYZE吗？
这是对上一个问题的评论的衍生：
使用 PostgreSQL 9.4，Recheck Cond:在EXPLAIN.
就像在EXPLAIN引用问题的输出中一样：
Run Code Online (Sandbox Code Playgroud)-> Bitmap Heap Scan on table_three (cost=2446.92..19686.74 rows=8159 width=7) Recheck Cond: (("timestamp" > (now() - '30 days'::interval)) AND (client_id > 0)) -> BitmapAnd (cost=2446.92..2446.92 rows=8159 width=0) -> Bitmap Index Scan on table_one_timestamp_idx (cost=0.00..1040.00 rows=79941 width=0) Index Cond: ("timestamp" > (now() - '30 days'::interval)) -> Bitmap Index Scan on fki_table_three_client_id (cost=0.00..1406.05 rows=107978 width=0) Index Cond: (client_id > 0)
或者在EXPLAIN ANALYZE一个简单的大表（很少work_mem）的输出中：
EXPLAIN ANALYZE …我有很多看起来像这样的表格：
CREATE TABLE table1(id INTEGER PRIMARY KEY, t1c1 INTEGER, t1c2 INTEGER);
CREATE TABLE table2(id INTEGER PRIMARY KEY, t1 INTEGER REFERENCES table1(id), t2c1 INTEGER);
我做了很多连接，我试图过滤连接表以从第一个表中获取内容，如下所示：
SELECT t1c1
FROM table1
JOIN table2 ON table2.t1 = table1.id
WHERE t2c1 = 42;
当我为表编写索引时，我会查看 WHERE 子句中使用的列并构建索引以满足它们。所以对于这个查询，我最终会写一个这样的索引：
CREATE INDEX ON table2 (t2c1);
并且这个索引至少有资格在该查询中使用。
我的问题是，如果我写这样的索引：
CREATE INDEX ON table2 (t2c1, t1);
索引会不会作为覆盖索引来帮助上面查询中的JOIN？我应该改变我的索引编写策略来覆盖外键列吗？
我正在通过 Heroku 使用 Postgres 9.3。
我有一个表，“交通”，有 100 万条记录，每天都有很多插入和更新。我需要在不同的时间范围内跨该表执行 SUM 运算，这些调用最多可能需要 40 秒，我很想听听有关如何改进它的建议。
我在这张桌子上有以下索引：
CREATE INDEX idx_traffic_partner_only ON traffic (dt_created) WHERE campaign_id IS NULL AND uuid_self <> uuid_partner;
这是一个示例 SELECT 语句：
SELECT SUM("clicks") AS clicks, SUM("impressions") AS impressions
FROM "traffic"
WHERE "uuid_self" != "uuid_partner"
AND "campaign_id" is NULL
AND "dt_created" >= 'Sun, 29 Mar 2015 00:00:00 +0000'
AND "dt_created" <= 'Mon, 27 Apr 2015 23:59:59 +0000'
这是解释分析：
Aggregate (cost=21625.91..21625.92 rows=1 width=16) (actual time=41804.754..41804.754 rows=1 loops=1)
-> Index Scan using idx_traffic_partner_only on …postgresql performance index optimization postgresql-9.3 postgresql-performance
假设一个充满产品的数据库。一个产品可以恰好属于 1 个集合并且由用户创建。数据库的粗略规模：
我正在尝试检索用户拥有的产品+集合的数量，以及每个集合中的产品数量（该信息应该在所有 x 天生成并在 ElasticSearch 中编入索引）。
对于用户查询，我目前正在做这样的事情：
SELECT
users.*,
(SELECT
count(*)
FROM
products product
WHERE
product.user_id = user.id
) AS product_count,
(SELECT
count(*)
FROM
collections collection
WHERE
collection.user_id = user.id
) AS collection_count
FROM
users user
所有 *_id 字段都已编入索引。使用解释（分析，详细）（删除敏感信息）：
Limit (cost=0.00..156500.97 rows=100 width=41) (actual time=0.064..28345.363 rows=100 loops=1)
Output: (...), ((SubPlan 1)), ((SubPlan 2))
-> Seq Scan on public.users user (cost=0.00..14549429167.11 rows=9296702 width=41) (actual time=0.064..28345.241 rows=100 loops=1)
Output: (...), (SubPlan 1), (SubPlan 2)
SubPlan 1 …我有一个名为“链接”的应用程序，其中 1) 用户聚集在群组中并添加其他人，2) 在上述群组中为彼此发布内容。组由links_group我的 postgresql 9.6.5 DB 中的表定义，而他们在这些中发布的回复由links_reply表定义。总体而言，DB 的性能非常好。
然而SELECT，links_reply表上的一个查询始终显示在slow_log 中。它花费的时间超过 500 毫秒，并且比我在大多数其他 postgresql 操作中遇到的速度慢约 10 倍。
我使用 Django ORM 来生成查询。这里的ORM电话：replies = Reply.objects.select_related('writer__userprofile').filter(which_group=group).order_by('-submitted_on')[:25]。本质上，这是为给定的组对象选择最新的 25 条回复。它还选择关联user和userprofile对象。
这是我的慢日志中相应 SQL 的示例：LOG: duration: 8476.309 ms 语句：
SELECT
"links_reply"."id", "links_reply"."text",
"links_reply"."which_group_id", "links_reply"."writer_id",
"links_reply"."submitted_on", "links_reply"."image",
"links_reply"."device", "links_reply"."category",
"auth_user"."id", "auth_user"."username",
"links_userprofile"."id", "links_userprofile"."user_id",
"links_userprofile"."score", "links_userprofile"."avatar"
FROM
"links_reply"
INNER JOIN "auth_user"
ON ("links_reply"."writer_id" = "auth_user"."id")
LEFT OUTER JOIN "links_userprofile"
ON ("auth_user"."id" = "links_userprofile"."user_id")
WHERE …postgresql performance upgrade postgresql-9.6 query-performance