Поиск по дате Postgres медленнее, чем vs больше чем - PullRequest
Новая
       7

Поиск по дате Postgres медленнее, чем vs больше чем

0 голосов
/ 14 февраля 2019

Я имею дело со странной проблемой, когда основанный на дате запрос выполняется намного медленнее при использовании >= против <=.Планы выполнения здесь:

Медленный

Быстрый

Похоже, когда он делает медленный, онделает 3 вложенных цикла, и когда он делает быстрый цикл, он выполняет соединение, но я не понимаю, почему.Я сделал вакуум, проанализировал и т.д. безрезультатно.

Вот и SQL тоже 

-- Table: public.hfj_spidx_date

-- DROP TABLE public.hfj_spidx_date;

CREATE TABLE public.hfj_spidx_date
(
    sp_id bigint NOT NULL,
    sp_missing boolean,
    sp_name character varying(100) COLLATE pg_catalog."default" NOT NULL,
    res_id bigint,
    res_type character varying(255) COLLATE pg_catalog."default" NOT NULL,
    sp_updated timestamp without time zone,
    hash_identity bigint,
    sp_value_high timestamp without time zone,
    sp_value_low timestamp without time zone,
    CONSTRAINT hfj_spidx_date_pkey PRIMARY KEY (sp_id),
    CONSTRAINT fk17s70oa59rm9n61k9thjqrsqm FOREIGN KEY (res_id)
        REFERENCES public.hfj_resource (res_id) MATCH SIMPLE
        ON UPDATE NO ACTION
        ON DELETE NO ACTION
)
WITH (
    OIDS = FALSE
)
TABLESPACE pg_default;

ALTER TABLE public.hfj_spidx_date
    OWNER to dbadmin;

-- Index: idx_sp_date_hash

-- DROP INDEX public.idx_sp_date_hash;

CREATE INDEX idx_sp_date_hash
    ON public.hfj_spidx_date USING btree
    (hash_identity, sp_value_low, sp_value_high)
    TABLESPACE pg_default;

-- Index: idx_sp_date_resid

-- DROP INDEX public.idx_sp_date_resid;

CREATE INDEX idx_sp_date_resid
    ON public.hfj_spidx_date USING btree
    (res_id)
    TABLESPACE pg_default;

-- Index: idx_sp_date_updated

-- DROP INDEX public.idx_sp_date_updated;

CREATE INDEX idx_sp_date_updated
    ON public.hfj_spidx_date USING btree
    (sp_updated)
    TABLESPACE pg_default;




 -------------------------------------


 -- Table: public.hfj_res_link

-- DROP TABLE public.hfj_res_link;

CREATE TABLE public.hfj_res_link
(
    pid bigint NOT NULL,
    src_path character varying(200) COLLATE pg_catalog."default" NOT NULL,
    src_resource_id bigint NOT NULL,
    source_resource_type character varying(30) COLLATE pg_catalog."default" NOT NULL,
    target_resource_id bigint,
    target_resource_type character varying(30) COLLATE pg_catalog."default" NOT NULL,
    target_resource_url character varying(200) COLLATE pg_catalog."default",
    sp_updated timestamp without time zone,
    CONSTRAINT hfj_res_link_pkey PRIMARY KEY (pid),
    CONSTRAINT fk_reslink_source FOREIGN KEY (src_resource_id)
        REFERENCES public.hfj_resource (res_id) MATCH SIMPLE
        ON UPDATE NO ACTION
        ON DELETE NO ACTION,
    CONSTRAINT fk_reslink_target FOREIGN KEY (target_resource_id)
        REFERENCES public.hfj_resource (res_id) MATCH SIMPLE
        ON UPDATE NO ACTION
        ON DELETE NO ACTION
)
WITH (
    OIDS = FALSE
)
TABLESPACE pg_default;

ALTER TABLE public.hfj_res_link
    OWNER to dbadmin;

-- Index: idx_rl_dest

-- DROP INDEX public.idx_rl_dest;

CREATE INDEX idx_rl_dest
    ON public.hfj_res_link USING btree
    (target_resource_id)
    TABLESPACE pg_default;

-- Index: idx_rl_src

-- DROP INDEX public.idx_rl_src;

CREATE INDEX idx_rl_src
    ON public.hfj_res_link USING btree
    (src_resource_id)
    TABLESPACE pg_default;

-- Index: idx_rl_tpathres

-- DROP INDEX public.idx_rl_tpathres;

CREATE INDEX idx_rl_tpathres
    ON public.hfj_res_link USING btree
    (src_path COLLATE pg_catalog."default", target_resource_id)
    TABLESPACE pg_default;

1 Ответ

0 голосов
/ 15 февраля 2019

Как я уже сказал в своем ответе на тот же вопрос, проблема заключается в неправильной оценке медленного запроса.

В быстром запросе PostgreSQL явно несделайте ошибку, думая, что условие очень избирательное, поэтому выбирает другой и лучший план.

...