Re: GiST for range types (was Re: Range Types - typo + NULL string constructor)
От | Jeff Davis |
---|---|
Тема | Re: GiST for range types (was Re: Range Types - typo + NULL string constructor) |
Дата | |
Msg-id | 1318064489.1724.83.camel@jdavis обсуждение исходный текст |
Ответ на | GiST for range types (was Re: Range Types - typo + NULL string constructor) (Alexander Korotkov <aekorotkov@gmail.com>) |
Ответы |
Re: GiST for range types (was Re: Range Types - typo + NULL
string constructor)
|
Список | pgsql-hackers |
On Fri, 2011-10-07 at 12:54 +0400, Alexander Korotkov wrote: > The first thing caught my eye in existing GiST code is idea of > subtype_float. float8 has limited precision and can't respresent, for > example, varlena values good enough. Even if we have large int8 value > we can loose lower bits, but data distribution can be so that these > bits are valuable. Wouldn't it better to have function like > subtype_diff_float which returns difference between two values of > subtype as an float? Using of such function could make penalty more > sensible to even small difference between values, and accordingly more > relevant. The reason I did it that way is for unbounded ranges. With subtype_diff_float, it's difficult for the GiST code to differentiate between [10,) and [100000,), because infinity minus anything is infinity. But when inserting the range [100,200), the penalty for the first one should be zero and the second one should have some positive penalty, right? Maybe we can still use subtype_diff_float by calling it on various pairs of bounds to come up with a reasonable cost? I'm open to suggestion. I'd just like to make sure that unbounded ranges are a part of the consideration. Regards,Jeff Davis
В списке pgsql-hackers по дате отправления: