Re: GiST -- making my index faster makes is slower - Mailing list pgsql-hackers

From Tom Lane
Subject Re: GiST -- making my index faster makes is slower
Date
Msg-id 3735.1082158550@sss.pgh.pa.us
Whole thread Raw
In response to Re: GiST -- making my index faster makes is slower  (David Blasby <dblasby@refractions.net>)
List pgsql-hackers
David Blasby <dblasby@refractions.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


pgsql-hackers by date:

Previous
From: Mark Kirkwood
Date:
Subject: Re: PostgreSQL configuration
Next
From: Kevin Brown
Date:
Subject: Re: PostgreSQL configuration