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

From Alexander Korotkov
Subject Re: GiST range-contained-by searches versus empty ranges
Date
Msg-id CAPpHfdsNHE+a+9im9ZacqnFgRcg8w2cwYn3EvV2KdYx5semK3g@mail.gmail.com
Whole thread Raw
In response to GiST range-contained-by searches versus empty ranges  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: GiST range-contained-by searches versus empty ranges
List pgsql-hackers
The first solution that comes to mind is to make the penalty and
picksplit functions forcibly segregate empty ranges from others, that is
a split will never put empty ranges together with non-empty ones.  Then,
we can assume that a non-empty internal node doesn't represent any empty
leaf entries, and avoid descending to it when it doesn't overlap the
target range.  Then the equality-search case could be improved too.

Thoughts, better ideas?

Have you seen my patch about GiST for range types?
There mentioned problem is solved by introduction of RANGE_CONTAIN_EMPTY bit in range flags. This bit is only used in GiST index and means that there are underlying empty ranges.

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

pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: GiST for range types (was Re: Range Types - typo + NULL string constructor)
Next
From: Peter Eisentraut
Date:
Subject: Re: vpath builds and verbose error messages