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

On Mon, Nov 28, 2011 at 3:00 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> I see your point that we only need the penalty values to be comparable
> for the same "new" value, but I don't think that really answers my
> objection, because you've had to lobotomize the logic. As an example,
> if we have a new empty range to insert, and all the existing root-page
> entries are ordinary finite ranges, this code will throw up its hands
> and give them all the same 4.0 penalty value. Surely it would be better
> to attempt to pick the smallest (narrowest) existing range. But to do
> that, you have to pay attention to the subdiff value.
>
I believe it's a problem of the current GiST interface. If using subdiff
value as an penalty for insertion of empty range, we have to return 0
penalty for any entry with RANGE_CONTAIN_EMPTY flag. And for plain empty
entry too without any chance to define priority between them. In my opinion
solution is that penalty function should return vector of floats instead of
single float. With current GiST interface we have to do will solution of
handling some cases better and some cases worse. For example, GiST for
boxes also suffers from interface limitation. In many papers I met
recommendation to choose smallest box from boxes with same extention (it's
not a rare situation to have multiple boxes with zero extention) for tuple
insertion. But with current interface, we can't implement it.

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