在处理文本搜索和地理空间数据时如何影响 Postgres 查询分析器

Question

以下语句存在相当严重的性能问题，我无法自行修复。

给定情况

• 我有一个安装了 Postgis 1.4 的 postgres 8.4 数据库
• 我有一个包含约 900 万个条目的地理空间表。此表有一个（postgis）几何列和一个 tsvector 列
• 我在几何上有一个 GIST 索引，在 vname 列上有一个 VNAME 索引
• 表是ANALYZE'd

我想在这些几何的子集中执行to_tsquerytext 搜索，这应该会返回所有受影响的 ID。

要搜索的区域会将 900 万个数据集限制为大约 100.000 个，并且该区域内 ts_query 的结果集很可能会输出 0..1000 个条目。

问题

查询分析器决定他想先对 vname 进行位图索引扫描，然后聚合并在几何体上放置一个过滤器（以及我在此语句中的其他条件）

查询分析器输出：

Aggregate  (cost=12.35..12.62 rows=1 width=510) (actual time=5.616..5.616 rows=1 loops=1)
->  Bitmap Heap Scan on mxgeom g  (cost=8.33..12.35 rows=1 width=510) (actual time=5.567..5.567 rows=0 loops=1)
     Recheck Cond: (vname @@ '''hemer'' & ''hauptstrasse'':*'::tsquery)
     Filter: (active AND (geom && '0107000020E6100000010000000103000000010000000B0000002AFFFF5FD15B1E404AE254774BA8494096FBFF3F4CC11E40F37563BAA9A74940490200206BEC1E40466F209648A949404DF6FF1F53311F400C9623C206B2494024EBFF1F4F711F404C87835954BD4940C00000B0E7CA1E4071551679E0BD4940AD02004038991E40D35CC68418BE49408EF9FF5F297C1E404F8CFFCB5BBB4940A600006015541E40FAE6468054B8494015040060A33E1E4032E568902DAE49402AFFFF5FD15B1E404AE254774BA84940'::geometry) AND (mandator_id = ANY ('{257,1}'::bigint[])))
     ->  Bitmap Index Scan on gis_vname_idx  (cost=0.00..8.33 rows=1 width=0) (actual time=5.566..5.566 rows=0 loops=1)
           Index Cond: (vname @@ '''hemer'' & ''hauptstrasse'':*'::tsquery)

这会导致大量 I/O - AFAIK 先限制几何体，然后再进行 vname 搜索会更聪明。

尝试的解决方案

为了实现我想要的行为

1. 我把 geom @@ AREA 放到一个子选择中 -> 没有改变执行计划
2. 我创建了一个带有所需区域子集的临时视图 -> 没有更改执行计划
3. 我创建了所需区域的临时表 -> 需要 4~6 秒才能创建，因此更糟。

顺便说一句，很抱歉没有发布实际查询：我认为如果我这样做了，我的老板会真的生我的​​气，而且我正在寻找更多的理论指针来解决我的实际查询。请询问您是否需要进一步说明

---

编辑

Richard 有一个非常好的观点：您可以使用 width 语句实现查询计划器的预期行为。坏事是这个临时表（或 CTE）弄乱了 vname 索引，因此在某些情况下使查询不返回任何内容。

我可以通过使用 to_tsvector() 即时创建新的 vname 来解决此问题，但这（太）昂贵 - 每个查询大约 300 到 500 毫秒。

我的解决方案

我放弃了 vname 搜索并使用了简单的 LIKE('%query_string%')（10-20 毫秒/查询），但这仅在我给定的环境中速度很快。 YMMV。

Answer 1

在 tsvector 的统计处理方面已经有了一些改进（我也认为 PostGIS，但我不使用它）。如果您有时间，可能值得再次尝试 9.1 版本，看看它对您有什么作用。

但是，对于这个单一查询，您可能需要查看 WITH 构造。

http://www.postgresql.org/docs/8.4/static/queries-with.html

如果您将几何部分作为 WITH 子句，它将首先评估（保证），然后该结果集将由以下 SELECT 过滤。不过，它可能最终会变慢，直到您尝试才知道。

对 work_mem 进行调整也可能会有所帮助 - 您可以在每个会话中执行此操作（“SET work_mem = ...”），但请注意将其设置得太高 - 并发查询会很快耗尽您的所有 RAM。

http://www.postgresql.org/docs/8.4/static/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-MEMORY