When should you NOT use a spatial index?

If your dataset is added to and updated often, then INSERT, DELETE and UPDATE statements which cause the index to be rebuilt may slow the database down.

For bulk inserts, such as loading the entire OSM dataset into a database, it may be quicker to drop the indices and create them again afterwards.

If it is more efficient to ignore an index (for example the table is small enough to be loaded into memory), the database query processor should do this automatically.

I'd expect the main reason to allow queries to be run without a spatial index is to measure the performance benefits you get by using an index, without having to drop it.

Finally if you want to show a huge performance boost to queries and map displays you may want to delay creating indices to an opportune moment in system development...

mapoholic,

Generally speaking, there isn't a reason to do a spatial query without a spatial index unless you are dealing with really small tables. Still though you would use the ST_ which don't use an index but do have the && indexable short circuit box operators. the functions that start with _ST are not meant to be used by end users. The reason they exist is because they have to. PostGIS spatial indexes use SQL inlining to force use of index -- the _ST is usually done by GEOS and the && is the index that may get reordered. So the _ST are really an implementation artifact.

so in short- its not one function so that the index operation can be reordered to happen all at once before the more intense spatial check.

I think this is implied, but I would NOT use a spatial index for a query when I had a non-spatial index that I could use instead. For example, I have 2,113,450 points that span the United States loaded into a table. If I wanted to pull all of the points that were within the state of Alaska, I could either do a spatial query that used the GIST index on the point geometries to compare against the geometry of the state of Alaska, OR, I could just use the "state_alpha" field in the point data (which is also indexed) to return all of the points that have "state_alpha" = 'AK'.

"Where is the spatial part of this", you ask? Well, if I need to do some further spatial analysis on the Alaska_points after I collect them, it's faster to gather up those point geometries using a non-spatial query first. It also means that for really big data sets, you benefit from adding a lookup field (or table). Again, I know this is probably obvious to everyone aleady, I only mention it because I encountered it in the past with global data sets that were only spatially indexed, and where a common query was "all features within a country". We gained alot of performance by adding an indexed country_fips field.

Below are some results from EXPLAIN ANALYZE that prove the point. (NOTE: I tried to make the spatial query as efficient as possible by using a BBOX query. Using the state outlines would have only made it slower.)

# 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