Question

我正在处理一个奇怪的问题，即使用>=与<=时，基于日期的查询运行得慢得多。执行计划在这里：

看起来它执行慢速循环时，它会执行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;

Answer 1

正如我对in my answer说的差不多一样，问题是缓慢查询中的估算错误。

在快速查询中，PostgreSQL显然不会误以为条件是选择性的，因此选择了一个更好的计划。

Postgres日期搜索的速度小于或大于

1 个答案: