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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Blasby <dblasby(at)refractions(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org, PostGIS Development Discussion <postgis-devel(at)postgis(dot)refractions(dot)net>
Subject: Re: GiST -- making my index faster makes is slower
Date: 2004-04-16 21:28:56
Message-ID: 2966.1082150936@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Blasby <dblasby(at)refractions(dot)net> 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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Blasby 2004-04-16 21:42:23 Re: GiST -- making my index faster makes is slower
Previous Message David Blasby 2004-04-16 19:26:46 Re: GiST -- making my index faster makes is slower