Re: GiST range-contained-by searches versus empty ranges - Mailing list pgsql-hackers

From Tom Lane
Subject Re: GiST range-contained-by searches versus empty ranges
Date
Msg-id 22941.1322587796@sss.pgh.pa.us
Whole thread Raw
In response to Re: GiST range-contained-by searches versus empty ranges  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
Jeff Davis <pgsql@j-davis.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: review: CHECK FUNCTION statement
Next
From: Pavel Stehule
Date:
Subject: Re: review: CHECK FUNCTION statement