hi,
> On 18.01.2012 14:07, Heikki Linnakangas wrote:
>> For 9.2, I think we should change gist so
>> that the user-defined distance function can return any scalar data type,
>> not just float8 (as long as it has b-tree comparison operators).
>
> I took a shot at doing that. Patch attached. It needs some cleanup; I
> think we'll need to bump the version of the btree_gist extension, and I
> only changed the btree_int8 distance function to do that, even though it
> would now make a lot of sense to adjust the others, too. Also, I think
> it'll leak memory (or crash..) if the distance data type is pass-by-ref.
>
> If someone has a test suite at hand for performance testing this, that
> would be good. Now that I'm calling the b-tree comparison function for
> every comparison operation in the red-black tree, instead of a direct
> float8 <= instruction, this could be quite a bit slower. That could be
> mitigated somewhat by using the sort-support stuff Tom committed recently.
>
> If we bend things a bit, this might be back-patchable to 9.1. We can't
> add a new am support function easily, that would require a catalog
> update to increment pg_am.amsupport entry, but we could hardwire the
> support for int8 distances, like I hardwired the knowledge of float8's
> comparsion function in the attached patch.
thanks for taking a look quickly.
i have some questions:
doesn't gbt_int8_distance overflow?
probably result += INT64_MIN so that it fits to int8 keeping the order?
isn't strategy number necessary to find out the sorting semantics for
the operator's sortfamily? (your patch doesn't change it, but...)
YAMAMOTO Takashi
>
> --
> Heikki Linnakangas
> EnterpriseDB http://www.enterprisedb.com
