Re: (9.1) btree_gist support for searching on "not equals"

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: (9.1) btree_gist support for searching on "not equals"
Date: 2010-08-02 16:27:46
Message-ID: AANLkTimvcgZqoch2RPY3tDu9rVzLrhePuoKG9mw_ADOY@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Aug 2, 2010 at 2:39 AM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> On Sun, 2010-08-01 at 21:57 -0400, Robert Haas wrote:
>> On Fri, Jul 16, 2010 at 1:19 AM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
>> > Thank you for the review.
>> >
>> > On Mon, 2010-07-12 at 17:17 +0900, Itagaki Takahiro wrote:
>> >> (1) Exclusion constraints support for operators where "x <operator> x"
>> >> is false (tiny patch)
>> >> https://commitfest.postgresql.org/action/patch_view?id=307
>> >> (2) btree_gist support for searching on <> ("not equals")
>> >> https://commitfest.postgresql.org/action/patch_view?id=308
>> >>
>> >> Those patches should be committed at once because (2) requires (1) to work
>> >> with EXCLUDE constraints. Also, (1) has no benefits without (2) because we
>> >> have no use cases for <> as an index-able operator. Both patches are very
>> >> simple and small, and worked as expected both "WHERE <>" and EXCLUDE
>> >> constraints cases.
>> >
>> > It appears that Tom already committed (1).
>> >
>> >> I'd like to ask you to write additional documentation about btree_gist [1]
>> >> that the module will be more useful when it is used with exclusion
>> >> constraints together. Without documentation, no users find the usages.
>> >
>> > Good idea, new patch attached.
>>
>> It seems pretty odd to define a constant called
>> BTNotEqualStrategyNumber in contrib/btree_gist.  Shouldn't we either
>> call this something else, or define it in access/skey.h?  Considering
>> that there seem to be some interesting gymnastics being done with
>> BTMaxStrategyNumber, I'd vote for the former.  Maybe just
>> BtreeGistNotEqualStrategyNumber?
>
> Sounds good to me.

OK, committed that way.

> At some point we may be interested to add this to BTree, as well. But we
> can cross that bridge when we come to it.

Yeah.

I was also wondering if it would be worth adding some additional
regression testing to contrib/btree_gist exercising this new
functionality. Thoughts?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2010-08-02 16:34:57 Re: Compiling CVS HEAD with clang under OSX
Previous Message Robert Haas 2010-08-02 16:14:19 Re: knngist - 0.8