> Note also that the btree optimization for << depends on having a
> plan-time-constant righthand side; so it's useless for joins, for
> instance. I didn't look closely, but I'd suppose that rtree could
> help for << searches without that constraint.
Indeed it can... tho rtree seems to be unable to do merge joins, so you
only get an index scan on one of the joined tables. Which index is
chosen has proven a bit hard to predict.
>
> Looking to the future, it might be better to base this on gist instead
> of rtree indexes --- gist is being worked on semi-actively, rtree isn't
> really being touched at all.
Yea, rtree is also broken, tho I think andrew is going to attempt fixing
it.
>
> But the immediate problem is that I don't think we can integrate this
> if it doesn't handle IPv6 addresses. We aren't going to want to
> backslide on having full IPv6 support.
Right,. i'll be adding ipv6 support...
... John