"Dolafi, Tom" <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
