Marios Vodas <mvodas@gmail.com> writes:
> I am implementing consistent, union, compress, decompress, penalty,
> picksplit and same.
[…]
> The problem is that some of these methods take as input parameters
> the d_type and some the struct type that I internally implemented in
> c (which will be saved to the tree).
That shouldn't be a problem as you're going to implement the functions
in C too, I guess. After all an index is all about performances.
http://www.postgresql.org/docs/current/static/gist-implementation.html
http://wiki.postgresql.org/wiki/Image:Prato_2008_prefix.pdf
Please not that the documentation here has been true in 8.3 too but
didn't get backpatched there. Maybe we should consider?
> If I understand correctly consistent and compress are the only
> functions that will have input parameter of d_type. The others will
> have my c internal type.
> Is this correct?
Well how is your C coded type different from d_type and why?
> Something else, will a non-leaf node have one entry that will be
> produced by union? I am asking because I want the leaf node entries
> to be of different type from non-leaf node entries (the difference
> between them is that non-leaf entry will not keep the id attribute).
Non-leaf nodes will contain a page full of entries all consistent with
each-other and sharing a common union. You can have leaf nodes entries
of a different type with the STORAGE option of the CREATE OPERATOR CLASS
command here, and the compress() and decompress() methods:
http://www.postgresql.org/docs/current/static/sql-createopclass.html
Then you have to take care about that in several of the functions in the
GiST API, in particular in consistent, see the GIST_LEAF(entry) macro.
Your main source of documentation at this point lies in the source of
the different GiST implementations, see ip4r, period, prefix and some
more.
Regards,
--
dim
