相关疑难解决方法(0)

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

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

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

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

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

我有一个由 Postgres 数据库支持的 Web API，性能通常非常好。我监控整个数据库和应用程序的性能。我的大部分查询（以及与此相关的 API 调用）都在不到 100 毫秒内完成，但偶尔会出现异常值。

就在今天，我收到一条警报，指出 API 调用耗时超过 5,000 毫秒，因此被看门狗终止。从挖掘日志开始，底层的 Postgres 查询花费了 13秒的时间来完成（一切都是异步的，所以即使 API 请求被终止，SQL 查询仍在继续）。

这是非常不典型的，即使当我手动运行有问题的查询时，我也无法重现这种糟糕的时间安排。它对我来说在 985 毫秒内完成（根据解释分析）。

我的问题

我不知道接下来还要看什么来尝试制定关于为什么会发生这种情况的理论。这种情况并不经常发生，每天只有成千上万次类似事件发生一次或两次，但它确实经常发生，令人讨厌。我错过了什么？我应该下一步做什么来调试它？我不是来自 DBA 背景，所以这可能是一个愚蠢的问题。

一些快速背景和我尝试过的

这一切都托管在 Amazon 的 RDS 上，在 m3.xlarge 上运行 Postgres 9.4，预配置 IOPS (2,000)。

我的一个表，我们称之为“详细信息”相当大，包含近 500 万行，并且以每天 25,000 条记录的速度增长。这个表永远不会更新或删除，只是插入和选择，但代表了我的应用程序的“核心”——几乎所有感兴趣的东西都是从这个表中读取的。

在这个特定情况下，我知道这个查询有一些参数（例如底部的日期和 id），因此它正在查看一个相当大的数据集。我已经开发了这个查询的一个大大改进的版本，它将这个特定场景从 985 毫秒减少到 20 毫秒。但是，我担心这里还有其他“在起作用”的东西，一个查询需要不到一秒的时间来运行我，在生产中时不时需要超过 13 秒。

桌子

嗯，有点……它包含更多的列，但我删除了任何不在查询中或没有索引的列。以下查询中使用的所有列或附加索引的所有列都已保留；

CREATE TABLE "public"."details" (
    "value" numeric,
    "created_at" timestamp(6) WITH TIME ZONE NOT NULL,
    "updated_at" timestamp(6) WITH TIME ZONE NOT NULL,
    "effective_date" timestamp(6) …

我有一个非常繁忙的功能，我需要以最佳方式优化。此函数只是一个嵌套的 select 语句，遗留应用程序每秒请求数次。

索引已就位，但我注意到它仅在第一次执行函数后使用。我认为问题在于 Postgres 创建了一个通用的执行计划，因为它在大多数情况下是高度排他的，但有时可能没有那么好。

当我EXPLAIN ANALYZE在第一次执行后进行测试时，查询运行得非常快，但应用程序会话仅调用该函数一次，然后终止。我需要第一次执行使用实际的优化计划。任何人都可以帮忙吗？

我们尝试弄乱管理连接池的连接器驱动程序来发出一个DISCARD TEMP而不是DISCARD ALL，因此它可以保持会话的缓存计划并且性能达到顶峰，但我不想在生产环境中这样做.

我们使用的是在 CentOS 6 上运行的 Postgres 9.4。我试过作为 SQL 函数运行，但没有帮助，它实际上作为 plpgsql 函数更快。下面是函数代码：

CREATE OR REPLACE FUNCTION public.ap_keepalive_geteqpid_veiid(
    IN tcbserie bigint,
    IN protocolo integer)
  RETURNS TABLE(eqpid integer, veiid integer, tcbid integer, veiplaca character varying, veiproprietariocliid integer, tcbtppid integer, tcbversao character, veirpmparametro double precision, tcbconfiguracao bigint, tcbevtconfig integer, veibitsalertas integer, sluid integer, harid integer) AS
$BODY$
BEGIN
    RETURN QUERY
    SELECT  teqp.eqpID, 
            teqp.eqpveiID AS veiID, 
            tcb.tcbID, 
            tvei.veiPlaca, 
            tvei.veiProprietariocliID, …

我使用的是较旧版本的 Postgres (8.4.20)。我知道 autovacuum 进程经常执行以释放删除或更新表中数据的查询的磁盘空间。我有一个不经常删除或更新的数据库。

在这样的数据库上处理 autovacuum 需要更少的时间和内存，还是仅取决于数据库中对象的大小和数量？

我有一个名为“链接”的应用程序，其中 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 …

我在视图中有一个非常大的查询（让我们称之为a_sql），这真的很快，除非我ORDER BY在SELECT带有小的外部使用LIMIT：

SELECT
customs.id AS custom_id, customs.custom_name AS custom_name, customs.slug AS slug, customs.use_case AS custom_use_case,
SUM(CASE WHEN designers.id = orders.user_id AND orders.bulk = 't' THEN order_rows.quantity ELSE 0 END) AS sale_bulk,
SUM(CASE WHEN designers.id = orders.user_id AND orders.bulk = 'f' THEN order_rows.quantity ELSE 0 END) AS sale_not_bulk,
SUM(CASE WHEN designers.id = orders.user_id THEN order_rows.quantity ELSE 0 END) AS sale_total,
SUM(CASE WHEN designers.id <> orders.user_id AND orders.bulk = 't' THEN order_rows.quantity ELSE 0 …