Как сделать этот запрос на удаление более быстрым?

Question

В одной базе данных есть две схемы - отары и овес Схемы полностью аналогичны друг другу.

Вот запрос, который я бегу, который принимает много времени

DELETE FROM oat.oat_user_tag_verification 
    using oatarchival.oat_user_tag_verification outv, oat.fp_archived f 
    WHERE outv.tag_id = f.tag_id and f.is_archived=false 
    and oat_user_tag_verification.user_id = outv.user_id and 
    oat_user_tag_verification.tag_id = outv.tag_id and 
    oat_user_tag_verification.verification_status = outv.verification_status 
    and oat_user_tag_verification.created_at=outv.created_at 
    and oat_user_tag_verification.updated_at=outv.updated_at 

Вот это объяснить многословным из этого запроса -

"Delete on oat.oat_user_tag_verification (cost=14989031.30..16227081.67 rows=1 width=18)" 
" -> Nested Loop (cost=14989031.30..16227081.67 rows=1 width=18)" 
"  Output: oat_user_tag_verification.ctid, outv.ctid, f.ctid" 
"  Join Filter: (outv.tag_id = f.tag_id)" 
"  -> Merge Join (cost=14989031.30..16021422.32 rows=1 width=28)" 
"    Output: oat_user_tag_verification.ctid, oat_user_tag_verification.tag_id, outv.ctid, outv.tag_id" 
"    Merge Cond: ((oat_user_tag_verification.tag_id = outv.tag_id) AND (oat_user_tag_verification.user_id = outv.user_id) AND (oat_user_tag_verification.verification_status = outv.verification_status) AND (oat_user_tag_verification.created_at = ou (...)" 
"    -> Sort (cost=13223314.06..13368102.38 rows=57915328 width=38)" 
"     Output: oat_user_tag_verification.ctid, oat_user_tag_verification.user_id, oat_user_tag_verification.tag_id, oat_user_tag_verification.verification_status, oat_user_tag_verification.created_at, oat_user_tag_verification.updated_at" 
"     Sort Key: oat_user_tag_verification.tag_id, oat_user_tag_verification.user_id, oat_user_tag_verification.verification_status, oat_user_tag_verification.created_at, oat_user_tag_verification.updated_at" 
"     -> Seq Scan on oat.oat_user_tag_verification (cost=0.00..1005001.28 rows=57915328 width=38)" 
"       Output: oat_user_tag_verification.ctid, oat_user_tag_verification.user_id, oat_user_tag_verification.tag_id, oat_user_tag_verification.verification_status, oat_user_tag_verification.created_at, oat_user_tag_verification.updated_at" 
"    -> Materialize (cost=1765717.25..1812477.56 rows=9352062 width=38)" 
"     Output: outv.ctid, outv.tag_id, outv.user_id, outv.verification_status, outv.created_at, outv.updated_at" 
"     -> Sort (cost=1765717.25..1789097.40 rows=9352062 width=38)" 
"       Output: outv.ctid, outv.tag_id, outv.user_id, outv.verification_status, outv.created_at, outv.updated_at" 
"       Sort Key: outv.tag_id, outv.user_id, outv.verification_status, outv.created_at, outv.updated_at" 
"       -> Seq Scan on oatarchival.oat_user_tag_verification outv (cost=0.00..171454.62 rows=9352062 width=38)" 
"        Output: outv.ctid, outv.tag_id, outv.user_id, outv.verification_status, outv.created_at, outv.updated_at" 
"  -> Seq Scan on oat.fp_archived f (cost=0.00..191863.83 rows=1103642 width=14)" 
"    Output: f.ctid, f.tag_id" 
"    Filter: (NOT f.is_archived)" 

Вот это создать таблицу структура все задействованные таблицы:

Таблица fp_archived:

CREATE TABLE fp_archived 
(
    tag_id bigint NOT NULL, 
    detection_url text, 
    image_id bigint NOT NULL, 
    pixel_x smallint NOT NULL, 
    camera_num smallint NOT NULL, 
    pixel_y smallint NOT NULL, 
    width smallint NOT NULL, 
    height smallint NOT NULL, 
    is_archived boolean DEFAULT false, 
    id bigint NOT NULL DEFAULT nextval('fp_archived_seq'::regclass), 
    drive_id character varying(255), 
    CONSTRAINT fp_archived_pkey PRIMARY KEY (id) 
) 

Таблица oat_user_tag_verification:

CREATE TABLE oatarchival.oat_user_tag_verification 
(
    user_id integer NOT NULL, 
    tag_id bigint NOT NULL, 
    verification_status integer NOT NULL, 
    created_at timestamp without time zone NOT NULL DEFAULT now(), 
    updated_at timestamp without time zone DEFAULT now(), 
    CONSTRAINT oat_user_tag_verification_pkey PRIMARY KEY (user_id, tag_id, verification_status, created_at), 
    CONSTRAINT oat_user_tag_verification_tag_id_fkey FOREIGN KEY (tag_id) 
     REFERENCES oatarchival.oat_tags (id) MATCH SIMPLE 
     ON UPDATE NO ACTION ON DELETE NO ACTION, 
    CONSTRAINT oat_user_tag_verification_user_id_fkey FOREIGN KEY (user_id) 
     REFERENCES oatarchival.oat_users (id) MATCH SIMPLE 
     ON UPDATE NO ACTION ON DELETE NO ACTION, 
    CONSTRAINT oat_user_tag_verification_verification_status_fkey FOREIGN KEY (verification_status) 
     REFERENCES oatarchival.oat_tag_verification_status (id) MATCH SIMPLE 
     ON UPDATE NO ACTION ON DELETE NO ACTION 
) 

Функция удаления запроса работает в течение нескольких часов и часов. Как я могу его оптимизировать? Какие индексы я должен создать для того, чтобы этот запрос стал быстрее?

Answer 1

Основываясь на вашем EXPLAIN выходе (к сожалению, вы не запускали EXPLAIN (ANALYZE)), я хотел бы предложить следующие показатели:

CREATE INDEX ON oatarchival.oat_user_tag_verification(
    ctid, 
    tag_id, 
    user_id, 
    verification_status, 
    created_at, 
    updated_at 
); 

CREATE INDEX ON oat.oat_user_tag_verification(
    tag_id, 
    user_id, 
    verification_status, 
    created_at, 
    updated_at 
); 

Они могут помочь с слиянием.

Тогда я бы создать следующий индекс:

CREATE INDEX ON oat.fp_archived(tag_id); 

Это ускорит вложенный цикл соединения.

Не уверен, что это лучший способ запустить запрос, но это отправная точка.

Answer 2

Один намек на плохой опыт - попробуйте поиграть с настройкой work_mem для сеанса. У меня была схожая проблема с невероятными затратами запросов на новый PostgreSQL 9.6 и fount, что для этого просто требуется более высокий предел work_mem.