RE: Indexing for geographic objects?
От | Edmar Wiggers |
---|---|
Тема | RE: Indexing for geographic objects? |
Дата | |
Msg-id | NEBBIAKDCDHFGJMLHCKIMENCCBAA.edmar@brasmap.com обсуждение исходный текст |
Ответ на | Re: Indexing for geographic objects? (selkovjr@mcs.anl.gov) |
Список | pgsql-hackers |
It seems that R-trees become inefficient when the number of dimensions increase. Has anyone thoght of a transparent way to use Peano codes (hhcode in Oracle lingo), and use B-tree indexes instead? Also, I've read that R-trees sometimes suffer a lot when an update overflows a node in the index. The only initial problem I see with Peano codes is that the index is made on real cubes (all dimensions are equal, due to the recursive decomposition of space). To overcome that, people have talked about using multiple-entry-indexes. That is, an object is decomposed in a number of cubes (not too many), which are then indexed. In this case, there should be a way to make intersection searches be transparent. Oracle does it using tables and merge-joins. I have thought of using GiST to do that, but it seemed too advanced for me yet. So I thought of using the Oracle technique (make tables and use joins). Problem: I would need a C function to make the cubes describing an spatial object, but currently C functions cannot return more than one value (have of thoght of returning an array, but have not tried it). And making inserts directly from a C function has been described as magic stuff in the documentation. Yours sincerely, Edmar Wiggers BRASMAP Information Systems +55 48 9960 2752
В списке pgsql-hackers по дате отправления: