From: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: GiST for range types (was Re: Range Types - typo + NULL string constructor) |
Date: | 2011-12-13 21:04:21 |
Message-ID: | CAPpHfdvxepwsCPiVZW72RYw0NXG=fot6GYoGZsq68UbU=WixTg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi!
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
> 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.
Attachment | Content-Type | Size |
---|---|---|
rangetypegist-0.5.patch.gz | application/x-gzip | 9.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2011-12-13 21:11:17 | Re: GiST for range types (was Re: Range Types - typo + NULL string constructor) |
Previous Message | Bruce Momjian | 2011-12-13 20:57:23 | Re: JSON for PG 9.2 |