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 по дате отправления:

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: Online base backup from the hot-standby
Следующее
От: Yeb Havinga
Дата:
Сообщение: Re: [REVIEW] Patch for cursor calling with named parameters