Postgresql 使用CTE调试性能问题

在我们的应用程序中，我们有一个用例，首先将csv文件复制到一个staging表中，然后将经过验证的数据插入第二个表participants。新创建的参与者id（主键）随后在staging表中更新，以便进一步处理

在我们的应用程序中，我们经常遇到性能问题。有时，此过程在15-20秒内处理100000行。有时，它永远不会在正常的时间内完成（pg_取消_后端救援）

当我试图创建一个如此有价值的最小测试用例时，我无法重现问题：/。因此，这是一个尝试，以获得一些建议，如何进一步调试或重写底层查询

• 带有DBAL的PHP应用程序
• 博士后10.5

我们使用CTE进行此操作-基本上如下所示：

WITH inserted_participants AS (
    INSERT INTO participants (email, project_id, survey_token, participant_uname)
    SELECT
        staging.email,
        1,
        staging.generated_token,
        staging.email -- is used as uname
    FROM
        staging
    RETURNING
        participants.participant_id,
        participants.participant_uname
) -- Update existing staging data with newly created participant_id
UPDATE
    staging  AS stage_update
SET
    resulting_participant_id = inserted_participants.participant_id
FROM
    inserted_participants
WHERE stage_update.email = inserted_participants.participant_uname;

再次声明：我无法重现这个测试用例的性能问题。我怀疑这与CTE有关

是否可以在不使用CTE的情况下重写，并且仍然可以安全地返回新创建的行并在暂存表中更新这些行

这是最小测试用例的表结构：

CREATE EXTENSION IF NOT EXISTS citext;

CREATE EXTENSION IF NOT EXISTS "pgcrypto";

DROP TABLE IF EXISTS public.staging;

CREATE TABLE public.staging
(
    staging_id serial,
    email citext COLLATE pg_catalog."default",
    generated_token character varying(255) COLLATE pg_catalog."default",
    resulting_participant_id integer,
    CONSTRAINT staging_pkey PRIMARY KEY (staging_id),
    CONSTRAINT unique_generated_token UNIQUE (generated_token)
);

CREATE INDEX ON public.staging (email);
CREATE INDEX ON public.staging (generated_token);

DROP TABLE IF EXISTS public.participants;

CREATE TABLE public.participants
(
    participant_id serial,
    email citext COLLATE pg_catalog."default" NOT NULL,
    project_id integer NOT NULL,
    survey_token character varying(255) COLLATE pg_catalog."default" NOT NULL,
    participant_uname citext COLLATE pg_catalog."default" NOT NULL,
    CONSTRAINT participants_pkey PRIMARY KEY (participant_id),
    CONSTRAINT participants_participant_uname_project_id_key UNIQUE (participant_uname, project_id),
    CONSTRAINT participants_project_id_email_key UNIQUE (project_id, email),
    CONSTRAINT participants_project_id_participant_uname_key UNIQUE (project_id, participant_uname),
    CONSTRAINT participants_survey_token_key UNIQUE (survey_token)
);

CREATE INDEX ON public.participants (participant_uname);
CREATE INDEX ON public.participants (project_id);

我使用的虚拟数据是：

INSERT INTO 
    staging (staging_id, email, generated_token)
SELECT 
    generate_series(1,100000),
    gen_random_uuid()::citext,
    gen_random_uuid()::TEXT;

---

您应该首先确定是否卡在锁中。

pg_锁

是否包含具有长时间运行的后端进程ID且

grated=FALSE的行

如果不是这样，找到瓶颈。后端进程是否会使CPU饱和？您的I/O子系统是否一直忙

您还应使用

EXPLAIN

检查执行计划。有什么可疑的东西可以解释持续时间吗

在查询完成的较小数据集上测试查询非常有用。这将使您能够运行

EXPLAIN（ANALYZE，BUFFERS）

，这是调试查询的最佳起点。但是，首先检查您是否有相同的执行计划

---

索引可以大大降低数据修改的速度。你有很多吗？通常，在批量更新之前删除所有索引和约束并在之后重新创建它们是最快的。

可能您被另一个会话阻止了。@LukaszSzozda我能够在我们的测试环境中，与其他用户/请求隔离地再现这一点。但是我们使用了一个单独的连接从stdin复制初始上传。如何检测会话阻塞？注意：您的更新中还有一个逻辑问题：

UNIQUE（project\u id，email），

只有电子邮件被用作连接条件。