Re: GiST Comparing IndexTuples/Datums

Good news:

I think we've got GiST working (somewhat anyways), as we found
gistKeyIsEQ(giststate,
0, datum, currdatum) in gistutil.c does the trick of comparing two datums.
I swear most of our trouble is just finding our way around the postgres
codebase, but we're getting there little by little. We've gone back to
revisit hash to see if we can figure it out now that we understand a little
bit about GiST, but we can't find an equivelent function in hash for the
KeyIsEQ().
So two questions really. The first is if such a function exists for
hash. The second is that nbtree and Neil Conways work a few years ago (
http://archives.postgresql.org/pgsql-patches/2003-09/msg00252.php) use the
scan and scankey stuff, but we're having trouble understanding how these
work. Is there some documentation on using these correctly (outside of just
looking at nbtree code)? Thanks so much for the help folks!

-Matt

On 2/13/07, Teodor Sigaev <teodor(at)sigaev(dot)ru> wrote:
>
> > indexes, then it must use operator number so-and-so for equality. But
> > there are lots of GiST opclasses that don't include equality at all; we
> > can't break that case.
>
> There is a GiST support function for equality of keys, in btree_gist it's
> named
> as gbt_*_same. Equality function has support number 7 and is used for
> stored keys.
>
> But the real issue in unique GiST index is unique :). First, the algorithm
> of
> insertion doesn't compare indexed keys on leaf page at all. Values on the
> same
> page are compared only when page is splitting (picksplit support method).
> Second, GiST implementation supports only unordered trees (btree_gist is a
> some
> kind of emulation) and it cannot guarantee that equal keys will be close
> in
> index. That's related to picksplit and gistpenalty method
> problem/optimization
> and data set.
>
> --
> Teodor Sigaev E-mail: teodor(at)sigaev(dot)ru
> WWW:
> http://www.sigaev.ru/
>