Hi Dimitri, list
> It seems to me that what you're asking for is addressed indirectly in
> the possibility to make your internal data type a full SQL visible
> datatype. Then you store this new datatype directly in the table and
> index that. Instead of converting from external to internal type at
> consistent() time in a query, provide an implicit CAST for external to
> internal for queries to "just work" without editing. The CAST will get
> called once per literal in the query.
Thanks for your reply. If there would be a way that the user never sees
the 'internal' type in query results (with some rules perhaps), it might
work. But somehow it feels 'not right'; the user datatype is the
external one, and how the gist index works internally should not be put
as burden on the user. The compression is also lossy, so recheck is
necessary and I think that will not work if only the internal type is
stored in the relation.
> See prefix and the prefix_range datatype as an example of this:
> http://blog.tapoueh.org/prefix.html
I wish I'd seen the slides on that link half a year ago, since I think
they are helpful to anyone that wants to start writing a gist index. I
remember using google translate on a russion page about gist in the
search for information. Besides that also reading Guttmans r-tree paper
was good, to have any idea what picksplit, penalty and union are
supposed to do.
regards,
Yeb Havinga