Skip site navigation (1) Skip section navigation (2)

Re: BUG #6399: knngist sometimes returns tuples in incorrect order

From: yamt(at)mwd(dot)biglobe(dot)ne(dot)jp (YAMAMOTO Takashi)
To: heikki(dot)linnakangas(at)enterprisedb(dot)com
Cc: pgsql-bugs(at)postgresql(dot)org, oleg(at)sai(dot)msu(dot)su, teodor(at)sigaev(dot)ru
Subject: Re: BUG #6399: knngist sometimes returns tuples in incorrect order
Date: 2012-01-19 04:35:17
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs

> 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

In response to


pgsql-bugs by date

Next:From: srinivas_j2eeDate: 2012-01-19 05:33:31
Subject: BUG #6402: Installer hung and wouldn't work again
Previous:From: bricklenDate: 2012-01-18 23:39:01
Subject: Re: BUG #6400: function arguments not accepted

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group