From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "John Hansen" <john(at)geeknet(dot)com(dot)au> |
Cc: | "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>, "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:51:00 |
Message-ID: | 27955.1119851460@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"John Hansen" <john(at)geeknet(dot)com(dot)au> writes:
> 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.
Mmm ... not really. It does seem that we could offer some sort of
generic set of gist support routines that understand rtree-like
semantics (all the picksplit routines seem suspiciously similar,
for instance). But seeing that every known instance of rtree support
has been broken since day one, partly for lack of any documentation
about what was needed, it's a bit hard to claim that implementing rtree
is transparently trivial.
> 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.
There's no HOWTO for rtree either. Again, my point is not that one
couldn't be written; it's that we would probably be better off spending
the effort on a HOWTO for gist.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2005-06-27 06:29:49 | Users/Groups -> Roles |
Previous Message | John Hansen | 2005-06-27 05:16:52 | Re: contrib/rtree_gist into core system? |