Skip site navigation (1) Skip section navigation (2)

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: GiST range-contained-by searches versus empty ranges
Date: 2011-11-29 17:29:56
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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

In response to

pgsql-hackers by date

Next:From: Pavel StehuleDate: 2011-11-29 17:37:24
Subject: Re: review: CHECK FUNCTION statement
Previous:From: Tom LaneDate: 2011-11-29 17:15:26
Subject: Re: review: CHECK FUNCTION statement

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group