Re: contrib/rtree_gist into core system?

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> "John Hansen" <john(at)geeknet(dot)com(dot)au> writes:
>
> > 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).

I think the picksplit part of the API is the strangest part. Normally when you
design data types you think in terms of your data type and the operations on
it. You shouldn't suddenly have to immerse yourself in some nitty gritty ADTs
for index pages.

I believe all the picksplit functions are based on (apparently via copy/paste)
a single algorithm that depends on a single operator: a kind of "distance"
function. Usually it's the same function underlying the penalty gist api
function. That's a natural operator to implement for data types and one that
doesn't involve learning about any extraneous implementation details of gist
indexing.

If gist index operator classes could be activated based entirely on data type
operators like "distance" and "union" and "penalty" instead of this strange
"picksplit" function then it would make implementing them *much* easier.

Moreover it would solve the multicolumn index issue. There are a probably
other options but the simplest would be to simply take the inner product of
the results of the various distance functions.

--
greg