13226，00000，“没有空间索引时不支持接口”
// *原因：几何表没有空间索引。 //
*操作：验证在空间
运算符中引用的几何表是否具有空间索引。
对我来说这很有意义。您运行空间查询=您必须具有空间索引。但是据我了解，PostGIS和SQL Serve都不需要这样做。 PostGIS甚至似乎具有明确表示将不使用空间索引的功能（_ *例如_STContains）。
所以问题是-在任何情况下都不应该使用空间索引吗？不一定是“采用还是放弃”方法，即没有任何区别，但是不使用空间索引会降低性能吗？对我来说，最后一句话在用语上是矛盾的，但是为什么PostGIS会提供这些功能呢？
#1 楼
mapoholic，一般来说，除非您要处理的是很小的表，否则没有理由不进行空间索引而进行空间查询。尽管您会使用ST_，它不使用索引，但具有&&可索引的短路盒运算符。
以_ST开头的功能并不供最终用户使用。它们存在的原因是因为它们必须这样做。 PostGIS空间索引使用SQL内联来强制使用索引-_ST通常由GEOS完成，而&&是可能重新排序的索引。因此_ST实际上是一个实现工件。
所以简而言之，它不是一个功能，因此可以在重新进行更激烈的空间检查之前立即将索引操作重新排序。
评论
欢呼声LR1234567。我想这就是我想要的。
–麻辣
11年7月28日在13:08
#2 楼
如果您的数据集被添加并经常更新，则导致重建索引的INSERT，DELETE和UPDATE语句可能会使数据库变慢。对于批量插入，例如将整个OSM数据集加载到数据库中，删除索引然后再创建它们可能会更快。
如果忽略索引的效率更高（例如，表足够小，可以装入内存），则数据库查询处理器应自动执行此操作。
我希望允许在没有空间索引的情况下运行查询的主要原因是评估使用索引所获得的性能收益，而不必删除它。
最后，如果您想对查询和地图显示显示出巨大的性能提升，则可能需要延迟在系统开发的适当时机创建索引...
评论
（+1）我在最后一句话中发现一点愤世嫉俗吗？ :-)
– hu
11年7月27日在13:37
一点都不; ;-)但是，删除/重新创建经过仔细调整的索引是“为什么X花费大量时间用于数据库更改”的有用答案？
– geoographika
11年7月27日在13:52
感谢geoca-我同意胡布尔的话！ ;-)我知道您将在批量加载时删除/禁用空间索引-或与此有关的所有索引，但是您无法想到为什么不使用空间索引就进行空间查询的原因？如果表足够小，则使用索引可能不会产生足够的公平（但选择不使用索引？）。不知道，我想我只是对PostGIS非空间索引功能的存在感到困惑...
–麻辣
2011年7月27日在14:07
如果表足够小并适合内存，则使用索引需要随机磁盘访问，这比进行顺序扫描的开销更大。 wiki.postgresql.org/wiki/…
– Sean
2011年7月27日14:26
@mapoholic-从old.nabble.com/判断，当您不得不手动对数据进行预过滤时，可能会遗留_ST_Contains。
– geoographika
11年7月27日在14:33
#3 楼
我认为这是隐含的，但是当我有可以使用的非空间索引时，就不会在查询中使用空间索引。例如，我有2,113,450个跨越美国的点加载到了表格中。如果我想提取阿拉斯加州内的所有点，则可以执行一个空间查询，该查询使用点几何上的GIST索引与阿拉斯加州的几何进行比较，或者，我可以使用点数据（也已建立索引）中的“ state_alpha”字段，以返回所有具有“ state_alpha” ='AK'的点。“此空间部分在哪里”，您问？好吧，如果需要在收集Alaska_points之后对它们做一些进一步的空间分析，则首先使用非空间查询来收集这些点的几何形状会更快。这也意味着对于真正的大数据集，您可以受益于添加查找字段（或表）。再一次，我知道这对于每个有领导能力的人来说都是显而易见的，我之所以只提到它，是因为我在过去遇到的问题是全局数据集，这些数据集仅在空间上建立索引，并且其中一个常见的查询是“一个国家的所有特征”。通过添加索引的country_fips字段，我们获得了很多性能。
以下是EXPLAIN ANALYZE的一些结果证明了这一点。 （注意：我试图通过使用BBOX查询来使空间查询尽可能高效。使用状态轮廓只会使其变慢。）
# explain analyze select count(*) from gnis_names where state_alpha = 'AK';
Aggregate (cost=57359.45..57359.46 rows=1 width=0) (actual time=76.606.. 76.607 rows=1 loops=1)
<snip>
Total runtime: 76.676 ms
# explain analyze select count(*) from gnis_names where the_geom && GeomFromText('POLYGON((-179.14734 51.219862,-179.14734 71.3525606439998,179.77847 71.3525606439998,179.77847 51.219862,-179.14734 51.219862))',4326);
Aggregate (cost=27699.86..27699.87 rows=1 width=0) (actual time=86.523..86.524 rows=1 loops=1)
<snip>
Total runtime: 86.584 ms
评论
非常感谢。当您说这话时，它似乎很明显，但是我的第一个想法是运行空间查询，而不是仅使用属性。为此+1！
–麻辣
11年7月29日在10:04
#4 楼
刚注意到这句话对我来说这很有意义。您运行空间查询=您必须具有
空间索引
对我来说这根本没有意义，我认为SQL Server和Postgis都可以做得更好或至少不会打扰您性能细节。
实际上，SQL Server和Postgis有时甚至根本不使用空间索引（恢复为全表扫描）。
对于Oracle，必须创建索引，因此必须填充user_sdo_geom_metadata。
仅将其与字母数字索引进行比较，出于性能原因它们就在那儿，您的SQL语句应该使用它，也可以不使用它。
在Oracle数据库中，删除索引，您将获得大量错误和无法使用空间查询的应用程序，因此无法正常工作。
评论
如果要查看索引使PostGIS变慢的位置，请设置enable_seqscan = off。这将迫使PostgreSQL每次使用索引。比较它的速度。感谢您启动此线程。我一直在网上查找信息，试图弄清为什么我的组织（政府）不使用其oracle / sde要素类和表中的空间（甚至属性）索引。现在，我要向他们提出一些论据，所以不必不必费劲就可以等待查询解决问题了。