On Mon, Nov 28, 2011 at 3:00 AM, Tom Lane <t...@sss.pgh.pa.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.