From: | "Edmar Wiggers" <edmar(at)brasmap(dot)com> |
---|---|
To: | <selkovjr(at)mcs(dot)anl(dot)gov>, "Franck Martin" <Franck(at)sopac(dot)org> |
Cc: | "'pgsql-general '" <pgsql-general(at)postgresql(dot)org>, "'pgsql-hackers '" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | RE: [HACKERS] Indexing for geographic objects? |
Date: | 2000-12-05 13:31:29 |
Message-ID: | NEBBIAKDCDHFGJMLHCKIMENCCBAA.edmar@brasmap.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general 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
From | Date | Subject | |
---|---|---|---|
Next Message | Mike Castle | 2000-12-05 13:56:05 | Re: Sequences in transaction |
Previous Message | The Hermit Hacker | 2000-12-05 13:02:28 | Re: mailing list |
From | Date | Subject | |
---|---|---|---|
Next Message | Marko Kreen | 2000-12-05 13:42:17 | Re: EAN13 for postgresql |
Previous Message | Larry Rosenman | 2000-12-05 10:10:58 | Re: Re: LOCK Fixes/Break on FreeBSD 4.2-STABLE |