索引对使用 && 的相交查询没有影响
Index has no effect on intersect query using &&
我在 PostgreSQL 数据库中有一个 table,它是使用以下命令通过 QGIS 数据库管理器创建的。 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)
)
我正在使用以下查询 return 作为 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);
在做上面的查询时,我发现查询之前大约需要700ms,而在我创建空间索引之后大约需要700ms。为了仔细检查,我复制了上面的 table,删除了两个索引,并且 运行 对两者进行了相同的查询并收到了几乎完全相同的结果。
是否有什么东西阻止查询使用我创建的索引?
虽然我不完全确定(我从来没有遇到过这个问题),但很可能是使用 ST_Shift_Longitude()
。 gist
索引适用于原始几何图形的框,但您使用该函数明确移动了西半球的几何图形。您可以尝试在函数结果上建立索引,看看是否有帮助:
CREATE INDEX "sidx_Hex15p625_geom_shift"
ON public.hex15p625
USING gist (ST_Shift_Longitude(geom));
我在 PostgreSQL 数据库中有一个 table,它是使用以下命令通过 QGIS 数据库管理器创建的。 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)
)
我正在使用以下查询 return 作为 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);
在做上面的查询时,我发现查询之前大约需要700ms,而在我创建空间索引之后大约需要700ms。为了仔细检查,我复制了上面的 table,删除了两个索引,并且 运行 对两者进行了相同的查询并收到了几乎完全相同的结果。
是否有什么东西阻止查询使用我创建的索引?
虽然我不完全确定(我从来没有遇到过这个问题),但很可能是使用 ST_Shift_Longitude()
。 gist
索引适用于原始几何图形的框,但您使用该函数明确移动了西半球的几何图形。您可以尝试在函数结果上建立索引,看看是否有帮助:
CREATE INDEX "sidx_Hex15p625_geom_shift"
ON public.hex15p625
USING gist (ST_Shift_Longitude(geom));