 
> As the aim here is performance one would hope that you are never doing
> sequential scans - so the bounding boxes in the index will suffice. 

Slow down there... just because you want to go fast doens't necessarily mean 
you will always be using a spatial index. If you are querying on another aspect 
of you data, in addition to a spatial extent eg. WHERE data_table.date=<mydate> 
AND geom_table.the_geom && <mybbox>, then it may be faster to use the index on 
your other data, and then use the bounding box to filter out those poly's that 
are outside of the bounding box. If you don't have the bbox stored in each 
record, and you have a lot of points in each record, this filtering process 
will slow down... not optimal.

For some data, and/or for some types of queries, it would be optimal to go 
without a bounding box... but for other data, and/or other queries, the 
bounding box is required for optimal performance. For the index, a float-based 
bbox should do the job as well as a double-based bbox.

Perhaps we could store the bounding box in a separate column, as a separate 
datatype. This way, if your system needs the bbox for optimal performance, you 
can include it yourself and update/use it where necesary. If you don't need it 
(probably the most general usage), then it will just be stored in the index. If 
it is a compile time option, it would mean that not all GIS applications will 
have the ability run optimally on one version of postgis... this seems like a 
serious downside. 

So, I guess that I would propose that we leave the bbox out of the lightweight 
wkb-geom type, and that one could add a column of type bbox if they need to use 
the bbox of their wkb-geoms.

My 2 bits worth.
Chris


