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
> it to do with more keys fitting in the leaf tuples.
Hm. With twice as many keys per page, you'd think that it could be no
more than 2x slower, if the problem is one of O(n) search through the
keys on the page. That doesn't explain a 10x slowdown. Could it be
that some part of the GIST code is O(n^2), or worse, in the number of
keys per page? If so, perhaps it's fixable.
I'd suggest profiling the backend with both key types to get an idea of
where the time is going.
regards, tom lane
PS: actually, allowing for the 12-byte index tuple overhead, you
couldn't have even twice as many keys per page. So there's something
mighty odd here. Keep us posted.
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
