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
Subject: Re: GiST -- making my index faster makes is slower
Date: 2004-04-16 23:35:50
Message-ID: 3735.1082158550@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:
> 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;
> float ymax;
> char junk[16];
> } BOX2DFLOAT4;

> This takes about 15,000 ms to do a nested query with 10,000 iterations.

That is strange --- I'm still suspecting an O(n^2) bit of logic
somewhere. But the size of the discrepancy is a little bit more
reasonable. Could you profile these two cases and see where the extra
time goes?

> typedef struct
> {
> double xmin;
> double ymin;
> double xmax;
> double ymax;
> } BOX2DFLOAT4;

> This takes about 1500 ms to do a nested query with 10,000 iterations.
> Yes - that almost 14 seconds faster!

AFAICS there are only two possible explanations:

1. float-vs-float comparison is a lot slower than double-vs-double on
your hardware. Actually, the comparisons might be float-vs-double
(is the "query" struct the same as the "key"??). The compiler could
well be promoting one or both floats to double and then doing double
comparison, but even so, that's a heck of a large overhead.

2. The float bounding boxes are presumably slightly inaccurate. If they
are a tad too large then perhaps you are visiting more leaf pages than
you need to. (A worrisome possibility is that a float box could be
slightly too small, causing you to fail to visit an entry you should
:-()

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Brown 2004-04-17 05:13:40 Re: PostgreSQL configuration
Previous Message Mark Kirkwood 2004-04-16 23:04:54 Re: PostgreSQL configuration