You link to the documentation of an old postgres version (9.2) that is not supported anymore (I know that google often puts these old links to the documentation at the top -- annoying).

But in this case there is an important distinction: recent postgres has default implementations of sp-gist. So the 'limitations' when implementing your own sp-gist class, while still true, need not worry us here. You will see that newer docs have a page "Built-in Operator Classes". My example uses the built-in sp-gist class. The 'limitations' are just warnings for those who implement their own sp-gist class.

It would be interesting to have an example dataset to compare the performance of any forthcoming pure-perl solution with what postgres indexing can do. Or graphic libraries (like you mentioned earlier).

> It would be interesting to have an example dataset to compare the performance of any forthcoming pure-perl solution with what postgres indexing can do. Or graphic libraries (like you mentioned earlier).

I'm trying not to cross that road. ;)

If you want you can compare it against a trivial bounding-box approach of spatial indexing.

You add 4 indexed columns for each polygon and use the formula from my first post to eliminate candidates°.

A simplistic pure Perl solution would probably imply sorted arrays, slices and hash intersections for the AND clause.

(Doesn't scale well but can handle 10000 polygons easily)

You already created your test sample, I doubt the OP ever will.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}

°) Nota bene: this doesn't calculate overlaps, it's just a poor man's spatial index to eliminate impossible combinations.