Re: contrib/rtree_gist into core system?

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

Responses

Browse pgsql-hackers by date

  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?