Mark, thank you very much for your response. As far as I understand, pre-computed bounding boxes are stored (by default) to each Geometry object (wherever that is) to "make bounding box based queries faster", see
http://main.merlin.com.ua/doc/postgis/docs/ch06.html#hasbbox http://main.merlin.com.ua/doc/postgis/docs/ch06.html#addbbox A full scan wouldn't be necessary if hasbbox(the_geom) returns true, which would make *much* sense here. Obviously this cached information is not evaluated when determining the bounding box while RECHECKing? Is this a "bug"? Mark, I have another question. I want to find out the *fastest* way to retrieve the binary content of Geometry objects to perform conversions later on. I found that SELECT the_geom returns a Geometry object in the hexewkb format and does not require any conversion operations by the database. Now, some questions occurred: a) Each selected Geometry object seems always to be copied into memory before one can access it, even static object data. Is there any "clean" way to access the raw data stored in the associated table files? b) hexewkb data must always be converted to bytes first in order to get integers or doubles. Is there any way to store geometric data directly as ewkb or wkb (btw, this would save 50% disc space)? c) double precision is not necessary to store coordinates if you know the SRID and the required accuracy. Is there any way to store geometric data in a format other than double, for example, float or int? d) How can I find out what disc files belong to a table, and how much disc space a particular table needs? Thank you again very much for your help!!! _______________________________________________________________________ Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 3 Monate kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=022220 _______________________________________________ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
