| From: | David Blasby <dblasby(at)refractions(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: GiST -- making my index faster makes is slower |
| Date: | 2004-04-16 21:42:23 |
| Message-ID: | 4080533F.8090404@refractions.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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 have even twice as many keys per page. So there's something
> mighty odd here. Keep us posted.
Using the old system, I'd get about 7 internal node hits and about 110
"leaf" hits. Under the new one, I get about 4 internal node hits and
about 160 "leaf" hits.
I'm just in the process of changing the key to:
typedef struct
{
float xmin;
float ymin;
float xmax;
float ymax;
char junk[16]; // make the 16 byte type into 32!
} BOX2DFLOAT4;
To see what happens.
dave
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2004-04-16 22:16:43 | Re: GiST -- making my index faster makes is slower |
| Previous Message | Tom Lane | 2004-04-16 21:28:56 | Re: GiST -- making my index faster makes is slower |