From: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: GiST range-contained-by searches versus empty ranges |
Date: | 2011-11-27 12:33:13 |
Message-ID: | CAPpHfdsNHE+a+9im9ZacqnFgRcg8w2cwYn3EvV2KdYx5semK3g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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?
https://commitfest.postgresql.org/action/patch_view?id=682
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2011-11-27 12:54:25 | Re: vpath builds and verbose error messages |
Previous Message | Alexander Korotkov | 2011-11-27 12:28:19 | Re: GiST for range types (was Re: Range Types - typo + NULL string constructor) |