On Mon, Dec 12, 2011 at 10:41 PM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> Thank you. I have attached a patch that's mostly just cleanup to this
Thanks a lot for cleanup. Path with applied cleanup is attached.
> * You use the term "ordinal range" quite a lot, which I haven't heard
> before. Is that a mathematical term, or do you mean something more like
Actually I meant "ordinal" range to be finite, non-empty and
non-contain-empty range. It's not mathematical term. Probably there is some
better word for that, but my english is not strong enough :).
> * There's a lot of code for range_gist_penalty. Rather than having
> special cases for all combinations of properties in the new an original,
> is it possible to use something a little simpler? Maybe just start the
> penalty at zero, and add something for each property of the predicate
> range that must be changed. The penalties added might vary, e.g., if the
> original range has an infinite lower bound, changing it to have an
> infinite upper bound might be a higher penalty.
I belive it's possible to make it simplier. I've coded quite intuitively.
Probably, we should select some representive datasets in order to determine
which logic is reasonable by tests.
* It looks like LIMIT_RATIO is not always considered. Should it be?
Yes, it's so. In this part I repeat logic of GiST with NULLs. It makes
NULLs to be separated from non-NULLs even if it's produce worse ratio. I'm
not sure about how it should be. It seems to be tradeoff between having
some excess pages and having slightly worse tree.
> * You defined get/set_range_contain_empty, but didn't use them. I think
> this was a merge error, but I removed them. So now there are no changes
> in rangetypes.c.
With best regards,
In response to
pgsql-hackers by date
|Next:||From: Alexander Korotkov||Date: 2011-12-13 21:11:17|
|Subject: Re: GiST for range types (was Re: Range Types - typo + NULL
|Previous:||From: Bruce Momjian||Date: 2011-12-13 20:57:23|
|Subject: Re: JSON for PG 9.2|