Re: GiST range-contained-by searches versus empty ranges

Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> On Sat, 2011-11-26 at 19:26 -0500, Tom Lane wrote:
>> I'm inclined to propose that we should add some logic to say that
>> merging a new item into an existing one is forbidden if the penalty
>> function returns plus-infinity for the case. If all existing items on a
>> page return infinity, a new item must be added to the page (possibly
>> causing a page split) instead of inserting into any existing one.
>> (Of course, gistpenalty() should be fixed to return infinity, not just a
>> randomly chosen large value, for the null-and-not-null case.)

> This seems less important now that you've committed the flag for
> "contains empty ranges".

> However, it still sounds like a useful improvement to me.

Actually, I'd pretty much decided that it was unworkable because of the
fact that GiST supports multi-column indexes. You can't have N columns
all trying to segregate their own special values without running out of
room on the root page.

It might well be that the GiST code should consider "add a new node to
the current internal page" in addition to "push the new value into one
of the existing nodes". But we can't let opclasses assume that the
division they'd like to have is guaranteed.

regards, tom lane