From: | "John Hansen" <john(at)geeknet(dot)com(dot)au> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> |
Cc: | "Greg Stark" <gsstark(at)mit(dot)edu>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: contrib/rtree_gist into core system? |
Date: | 2005-06-27 05:16:52 |
Message-ID: | 5066E5A966339E42AA04BA10BA706AE50A9379@rodrick.geeknet.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane Wrote:
> ... but rtree has always
> been marginal, and it's very hard to see where it can win over gist.
Simplicity!
Implementing rtree operators and support functions is FAR simpler than
implementing the GiST equivalents.
For example, suppose all you want to implement is the ~ operator for a
custom type, then technically all you need is 4 functions (well, 5
including the stub operators)
bool contains(type,type);
type intersect(type,type);
type union(type,type);
void size(type,*float);
And the 6 other operators simply defined as:
bool false(type) { return false; }
For GiST you still need 7 support functions + the operator function,
some of which aren't exactly simple to implement, the picksplit for
instance.
So I'd not recommend getting rid of rtree just yet. At least not until
someone has written an extensive howto on the subject of GiST
implementation.
... John
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-06-27 05:51:00 | Re: contrib/rtree_gist into core system? |
Previous Message | Tom Lane | 2005-06-27 04:57:25 | Re: contrib/rtree_gist into core system? |