Postgres日期搜索速度慢于小于大于

Question

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

Slow

Fast

看起来当它做慢速时，它会做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显然没有错误地认为条件是非常有选择性的，所以它选择了一个不同的更好的计划。