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 | 1318840692.10757.34.camel@jdavis обсуждение исходный текст |
Ответ на | Re: GiST for range types (was Re: Range Types - typo + NULL string constructor) (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: GiST for range types (was Re: Range Types - typo + NULL
string constructor)
|
Список | pgsql-hackers |
On Sun, 2011-10-16 at 14:43 -0700, Jeff Davis wrote: > 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. > > > I started implementing subtype_diff, and I noticed that it requires > defining an extra function for each range type. Previously, the numeric > types could just use a cast, which was convenient for user-defined range > types. > > If you have any other ideas to make that cleaner, please let me know. > Otherwise I'll just finish implementing subtype_diff. I'm beginning to think that we should just allow the user to specify their own gist_penalty function. Specifying just the subtype_diff doesn't save much time, and it can only be limiting. Additionally, it's harder for users to understand the purpose of the function. Regards,Jeff Davis
В списке pgsql-hackers по дате отправления: