Re: rtree/gist index taking enormous amount of space in 8.2.3 - Mailing list pgsql-performance

From Tom Lane
Subject Re: rtree/gist index taking enormous amount of space in 8.2.3
Date
Msg-id 6932.1183142291@sss.pgh.pa.us
Whole thread Raw
In response to Re: rtree/gist index taking enormous amount of space in 8.2.3  ("Dolafi, Tom" <dolafit@janelia.hhmi.org>)
Responses Re: rtree/gist index taking enormous amount of space in 8.2.3  ("Dolafi, Tom" <dolafit@janelia.hhmi.org>)
List pgsql-performance
"Dolafi, Tom" <dolafit@janelia.hhmi.org> writes:
> In the mean time I've dropped the index which has resulted in overall
> performance gain on queries against the table, but we have not tested
> the part of the application which would utilize this index.

I noted that with the same (guessed-at) distribution of fmin/fmax, the
index size remains reasonable if you change the derived boxes to

CREATE OR REPLACE FUNCTION boxrange(integer, integer)
  RETURNS box AS
    'SELECT box (point($1, $1), point($2, $2))'
  LANGUAGE 'sql' STRICT IMMUTABLE;

which makes sense from the point of view of geometric intuition: instead
of a bunch of very tall, mostly very narrow, mostly overlapping boxes,
you have a bunch of small square boxes spread out along a line.  So it
stands to reason that a geometrically-motivated index structure would
work a lot better on the latter.  I don't know though whether your
queries can be adapted to work with this.  What was the index being used
for, exactly?

            regards, tom lane

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: rtree/gist index taking enormous amount of space in 8.2.3
Next
From: "Dolafi, Tom"
Date:
Subject: Re: rtree/gist index taking enormous amount of space in 8.2.3