> 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...)
> Heikki Linnakangas
> EnterpriseDB http://www.enterprisedb.com
In response to
pgsql-bugs by date
|Next:||From: srinivas_j2ee||Date: 2012-01-19 05:33:31|
|Subject: BUG #6402: Installer hung and wouldn't work again|
|Previous:||From: bricklen||Date: 2012-01-18 23:39:01|
|Subject: Re: BUG #6400: function arguments not accepted|