Skip site navigation (1) Skip section navigation (2)

Re: GiST for range types (was Re: Range Types - typo + NULL string constructor)

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 (view raw or flat)
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: rangetypegist-0.5.patch.gz
Description: application/x-gzip (9.8 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Alexander KorotkovDate: 2011-12-13 21:11:17
Subject: Re: GiST for range types (was Re: Range Types - typo + NULL string constructor)
Previous:From: Bruce MomjianDate: 2011-12-13 20:57:23
Subject: Re: JSON for PG 9.2

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group