Hi!
On Mon, Dec 12, 2011 at 10:41 PM, Jeff Davis
<pgsql@j-davis.com> wrote:
Thank you. I have attached a patch that's mostly just cleanup to this
one.
Thanks a lot for cleanup. Path with applied cleanup is attached.
Comments:
* 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
"ordinary"?
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.
Ok, thanks.
------
With best regards,
Alexander Korotkov.