GiST for range types (was Re: Range Types - typo + NULL string constructor) - Mailing list pgsql-hackers

From Alexander Korotkov
Subject GiST for range types (was Re: Range Types - typo + NULL string constructor)
Date
Msg-id CAPpHfduGQ==r0sf7JFG5C=EBbyc5v=jFhhzg0Kqgm76cbGARoQ@mail.gmail.com
Whole thread Raw
Responses 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)  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
On Fri, Oct 7, 2011 at 7:41 AM, Jeff Davis <pgsql@j-davis.com> wrote:
I'd prefer to include it in the initial patch. If the current GiST code
is going to be replaced, then there's not much sense reviewing/testing
it.

You may need to consider unbounded and empty ranges specially. I made an
attempt to do so in the current GiST code, and you might want to take a
look at that first. I'm not particularly attached to my approach, but we
should do something reasonable with unbounded and empty ranges.

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.

------
With best regards,
Alexander Korotkov. 

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable
Next
From: Andrea Suisani
Date:
Subject: [OT?] Time-zone database down [was: Re: timezone buglet?]