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 | 1318091273.1724.89.camel@jdavis обсуждение исходный текст |
Ответ на | Re: GiST for range types (was Re: Range Types - typo + NULL string constructor) (Alexander Korotkov <aekorotkov@gmail.com>) |
Список | pgsql-hackers |
On Sat, 2011-10-08 at 18:43 +0400, Alexander Korotkov wrote: > I meant that penalty can be determined as sum of difference of old and > new bounds of range, i.e. penalty = subtype_diff_float(new_lower, > old_lower) + subtype_diff_float(old_upper, new_upper). > When we insert [100,200) into [10,+inf), union([100,200), [10,+inf)) > = [10,+inf), so penalty = subtype_diff_float(10,10) > + subtype_diff_float(+inf, +inf) = 0 + 0 = 0. > When we insert [100,200) into [100000,), union([100,200), [100000, > +inf)) = [100,+inf), so penalty = subtype_diff_float(100,100000) > + subtype_diff_float(+inf, +inf) = 99900 + 0 = 99900. > OK, I like that. I will make the change. > But, there are still the problem, when we'are inserting open interval > when there is no such open intervals yet. For example, we're going to > insert [0,+inf), while root page contains [0,10), [10,20), [20,30). > Each penalty will be infinity, while it seems to be better to insert > it into [0,10). But, it seems to me to be general limitation of > current GiST interface, when we have to express penalty in a single > float. That seems like an acceptable limitation. I don't think my solution handles it any better. Regards,Jeff Davis >
В списке pgsql-hackers по дате отправления: