From: | Jay Levitt <jay(dot)levitt(at)gmail(dot)com> |
---|---|
To: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Designing an extension for feature-space similarity search |
Date: | 2012-02-17 20:47:35 |
Message-ID: | 4F3EBCE7.4050808@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alexander Korotkov wrote:
> On Fri, Feb 17, 2012 at 11:32 PM, Jay Levitt <jay(dot)levitt(at)gmail(dot)com
> 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.
That makes sense; you're essentially keeping one bit of stats about the
values present in the range.
I wonder: if I'm indexing a rowtype, then for each column in the row I need
to store a lower-left and an upper-right bound, plus a might-have-nulls
flag. Sounds a lot like a range. Should I just use ranges for that? See a
downside (overhead)? See an upside (seems less duplicative somehow)? I'm
fine depending on 9.2.
Jay
From | Date | Subject | |
---|---|---|---|
Next Message | Thom Brown | 2012-02-17 20:58:59 | Re: Triggers with DO functionality |
Previous Message | Dimitri Fontaine | 2012-02-17 20:40:13 | Re: Triggers with DO functionality |