索引對使用&&

Question

的相交查詢沒有影響我在使用以下命令通過QGIS DB Manager創建的PostgreSQL數據庫中有一個表。 geom列包含大約500,000個六邊形多邊形，而centroid列存儲那些六邊形的質心。 id只是分配給每個值的唯一值。

CREATE TABLE public.hex15p625 
(
    id integer NOT NULL DEFAULT nextval('"Hex15p625_id_seq"'::regclass), 
    geom geometry(Polygon,4326), 
    centroid geometry(Point,4326), 
    CONSTRAINT "Hex15p625_pkey" PRIMARY KEY (id) 
) 

我使用下面的查詢返回的GeoJSON的下降邊框內的任何六邊形：

SELECT id, ST_AsGeoJSON(geom) AS geom, ST_AsGeoJSON(centroid) AS centroid 
FROM public.hex15p625 
WHERE 
    ST_Shift_Longitude(public.hex15p625.geom) && 
    ST_Shift_Longitude(ST_MakeEnvelope(-86.0057, 48.8199, -85.6854, 48.9955, 4326)); 

爲了加快查詢，我創建了兩個指標，但只有一個在使用用例以上：

CREATE INDEX "sidx_Hex15p625_geom" 
    ON public.hex15p625 
    USING gist 
    (geom); 
ALTER TABLE public.hex15p625 CLUSTER ON "sidx_Hex15p625_geom"; 

而這一次，這我只是把這裏完整起見：

CREATE INDEX "sidx_Hex15p625_centroid" 
    ON public.hex15p625 
    USING gist 
    (centroid); 

在進行上述查詢時，我發現查詢在創建空間索引之前花費了大約700毫秒和700毫秒。爲了仔細檢查，我製作了上述表的副本，刪除了兩個索引，並針對兩者運行了相同的查詢，並收到了幾乎完全相同的結果。

是否有東西阻止查詢使用我創建的索引？

Answer 1

儘管我不完全確定（我從來沒有遇到過這個問題），但最有可能的是使用ST_Shift_Longitude()。 gist索引與原始幾何圖形的框一起使用，但是您使用該函數明確地移動了西半球的幾何圖形。你可以嘗試建立一個索引的功能結果，看看是否有幫助：

CREATE INDEX "sidx_Hex15p625_geom_shift" 
    ON public.hex15p625 
    USING gist (ST_Shift_Longitude(geom));