Re: GiST -- making my index faster makes is slower

> Couple of observations:
> 
> 1. Are you sure your data is handled as 32 bit all the way through?  Run
> time casting will offset performance gains on 32 bit floats.  Is your
> comparison routine casting to double?

I thought this might be the case - but I thought it would be small.  The 
only place it might be doing hidden casts would be in statements like
"query->xmin <= key->xmax".


> 2. Math CPUs usually crunch at 80 bits, can't save much by using 32 bit
> floats, although cache coherency will be better.
> 
> 3. 64 bit cpu will probably run better on 64 bit floats.
> 
> 4. Is your dataset congested enough that you now have duplicate values
> by loss of precision?   This would of course impact performance.  How
> big is your dataset?  How big is your avg. result set?

My test datasets are quite spatially separate, so I dont expect there to 
be any "accidental" overlaps.  There's about 12 million rows (in total) 
in the datasets - I've only noticed about 2 of these overlaps.  My test 
datasets are 1000 rows, 10,000 rows, 10,000,000 rows, and a few 
different ones in the 200,000 row range.

I'm testing queries that return anywhere from 1 geometry to about 10,000.

The actual index search is only a few milliseconds longer using the 
float32 bounding box for a mid-sized table returning a handfull of rows.  When the result sets get bigger (or you start
doingnested queries), 
 
the performance differences become greater.

dave