I tracked the problem down to the "penalty" function used to build the
tree. Basically, it compares the area of the bounding boxes.
There wasnt enough precision in the area calculations - instead of
giving 0.0 it would give numbers in the[+-]10^-6 range. This really
screwed up how the tree w
David Blasby <[EMAIL PROTECTED]> writes:
> Humm -- strange results here:
> typedef struct
> {
> float xmin;
> float ymin;
> float xmax;
> float ymax;
> } BOX2DFLOAT4;
> This takes about 18,000 ms to do a nested query with 10,000 iterations.
> typedef struct
> {
> flo
Humm -- strange results here:
typedef struct
{
float xmin;
float ymin;
float xmax;
float ymax;
} BOX2DFLOAT4;
This takes about 18,000 ms to do a nested query with 10,000 iterations.
typedef struct
{
float xmin;
float ymin;
float xmax;
David Blasby <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I'd suggest profiling the backend with both key types to get an idea of
>> where the time is going.
> I've been trying to use gprof to do some profiling, but I'm having
> troubles. Whats the best way to profile?
It's not hard; the on
Tom Lane wrote:
I'd suggest profiling the backend with both key types to get an idea of
where the time is going.
I've been trying to use gprof to do some profiling, but I'm having
troubles. Whats the best way to profile?
PS: actually, allowing for the 12-byte index tuple overhead, you
couldn't
David Blasby <[EMAIL PROTECTED]> writes:
> The old way used a BOX (bounding box of 4 doubles) as the key in the index.
> The new way uses a bounding box of 4 single-precision floats (its only
> 16 bytes long - a BOX is 32).
> It turns out this is not the case - its significantly slower. I think
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
I just tried an experiment that I thought would improve the performance
of the PostGIS spatial index.
The old way used a BOX (bounding box of 4 doubles) as the key in the index.
The new way uses a bounding box of 4 single-precision floats (its only
16 bytes long - a BOX is 32). I thought that
