Question

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

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

当我尝试创建一个非常有价值的最小测试用例时，我无法重现该问题：/。因此，这是尝试获取一些建议以进行进一步调试或重写基础查询的建议。

带有Doctrine DBAL的PHP App
Postgres 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;

Answer 1

您首先应该确定自己是否被锁住。 pg_locks是否包含具有长时间运行的后端的进程ID和granted = FALSE的行？

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

您还应该使用EXPLAIN检查执行计划。有什么可解释时间的可疑之处吗？

在完成的较小数据集上测试查询非常有帮助。这将使您能够运行EXPLAIN (ANALYZE, BUFFERS)，这是调试查询的最佳起点。不过，请先检查您是否有相同的执行计划。

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

使用CTE调试性能问题

1 个答案: