PostGIS 1.5.8 Manual - Fedora Project Packages GIT repositories

PostGIS 1.5.8 Manual50 / 310SELECT geom_columnFROM mytableWHERE bbox && ST_SetSRID(’BOX3D(0 0,1 1)’::box3d,4326);Of course, if you change or add rows to mytable, you have to keep the bbox "in sync". The most transparent way to do this wouldbe triggers, but you also can modify your application to keep the bbox column current or run the UPDATE query above afterevery modification.6.2 CLUSTERing on geometry indicesFor tables that are mostly read-only, and where a single index is used for the majority of queries, PostgreSQL offers the CLUS-TER command. This command physically reorders all the data rows in the same order as the index criteria, yielding twoperformance advantages: First, for index range scans, the number of seeks on the data table is drastically reduced. Second, ifyour working set concentrates to some small intervals on the indices, you have a more efficient caching because the data rowsare spread along fewer data pages. (Feel invited to read the CLUSTER command documentation from the PostgreSQL manualat this point.)However, currently PostgreSQL does not allow clustering on PostGIS GIST indices because GIST indices simply ignores NULLvalues, you get an error message like:lwgeom=# CLUSTER my_geom_index ON my_table;ERROR: cannot cluster when index access method does not handle null valuesHINT: You may be able to work around this by marking column "the_geom" NOT NULL.As the HINT message tells you, one can work around this deficiency by adding a "not null" constraint to the table:lwgeom=# ALTER TABLE my_table ALTER COLUMN the_geom SET not null;ALTER TABLEOf course, this will not work if you in fact need NULL values in your geometry column. Additionally, you must use the abovemethod to add the constraint, using a CHECK constraint like "ALTER TABLE blubb ADD CHECK (geometry is not null);" willnot work.6.3 Avoiding dimension conversionSometimes, you happen to have 3D or 4D data in your table, but always access it using OpenGIS compliant ST_AsText() orST_AsBinary() functions that only output 2D geometries. They do this by internally calling the ST_Force_2d() function, whichintroduces a significant overhead for large geometries. To avoid this overhead, it may be feasible to pre-drop those additionaldimensions once and forever:UPDATE mytable SET the_geom = ST_Force_2d(the_geom);VACUUM FULL ANALYZE mytable;Note that if you added your geometry column using AddGeometryColumn() there’ll be a constraint on geometry dimension. Tobypass it you will need to drop the constraint. Remember to update the entry in the geometry_columns table and recreate theconstraint afterwards.In case of large tables, it may be wise to divide this UPDATE into smaller portions by constraining the UPDATE to a part of thetable via a WHERE clause and your primary key or another feasible criteria, and running a simple "VACUUM;" between yourUPDATEs. This drastically reduces the need for temporary disk space. Additionally, if you have mixed dimension geometries,restricting the UPDATE by "WHERE dimension(the_geom)>2" skips re-writing of geometries that already are in 2D.