Re: Designing an extension for feature-space similarity search - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: Designing an extension for feature-space similarity search
Date
Msg-id CAPpHfdsH7j15s-RR5NfaciJQgh55NkfShSvFxTi4PHA9JZuoqg@mail.gmail.com
Whole thread Raw
In response to Re: Designing an extension for feature-space similarity search  (Jay Levitt <jay.levitt@gmail.com>)
Responses Re: Designing an extension for feature-space similarity search
List pgsql-hackers
On Fri, Feb 17, 2012 at 11:32 PM, Jay Levitt <jay.levitt@gmail.com> wrote:
Alexander Korotkov wrote:
On Fri, Feb 17, 2012 at 11:00 PM, Jay Levitt <jay.levitt@gmail.com
<mailto:jay.levitt@gmail.com>> wrote:

   At first I thought this posed a challenge for union; if I have these points:

   (1,2)
   (2,1)
   (1,NULL)

   what's the union? I think the answer is to treat NULL box coordinates
   like LL = -infinity, UR = infinity, or (equivalently, I think) to store
   a saw_nulls bit in addition to LL and UR.

Similar problem appears at GiST indexing of ranges, because range can be
empty. There additional "contain empty" flag was introduced. This "contain
empty" flag indicates that underlying value can be empty. So, this flag is
set when union with empty range or other range with this flag set. It's
likely you need similar flag for each dimension.

Ah, yes, exactly the same problem. So what led you to add a flag instead of using the range NULL..NULL? I'm on the fence about choosing.

At first, range bounds can't be NULL :) At second, if we have range (a;b)+"contain empty" in internal page, both facts:
1) All normal underlying ranges are contained in (a;b).
2) There can be empty underlying ranges.
are useful for search.

------
With best regards,
Alexander Korotkov. 

pgsql-hackers by date:

Previous
From: Don Baccus
Date:
Subject: Re: MySQL search query is not executing in Postgres DB
Next
From: Andrew Dunstan
Date:
Subject: Re: MySQL search query is not executing in Postgres DB