Re: Designing an extension for feature-space similarity search
| От | Jay Levitt |
|---|---|
| Тема | Re: Designing an extension for feature-space similarity search |
| Дата | |
| Msg-id | 4F3EBCE7.4050808@gmail.com обсуждение исходный текст |
| Ответ на | Re: Designing an extension for feature-space similarity search (Alexander Korotkov <aekorotkov@gmail.com>) |
| Список | pgsql-hackers |
Alexander Korotkov wrote: > On Fri, Feb 17, 2012 at 11:32 PM, Jay Levitt <jay.levitt@gmail.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
В списке pgsql-hackers по дате отправления: