From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, pgsql-hackers(at)postgresql(dot)org, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, Teodor Sigaev <teodor(at)sigaev(dot)ru> |
Subject: | Re: Extending opfamilies for GIN indexes |
Date: | 2011-01-19 18:37:59 |
Message-ID: | AANLkTimKikC1wQWCMtssRva8oX5ttpBk+88C7e2547CS@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jan 19, 2011 at 1:33 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Wed, Jan 19, 2011 at 12:29 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> I think you missed the point: right now, to use both the core and
>>> intarray operators on an integer[] column, you have to create *two*
>>> GIN indexes, which will have exactly identical contents. I'm looking
>>> for a way to let intarray extend the core opfamily definition so that
>>> one index can serve.
>
>> Maybe this is a dumb question, but why not just put whatever stuff
>> intarray[] adds directly into the core opfamily?
>
> AFAICS that means integrating contrib/intarray into core. Independently
> of whether that's a good idea or not, PG is supposed to be an extensible
> system, so it would be nice to have a solution that supported add-on
> extensions.
Yeah, I'm just wondering if it's worth the effort, especially in view
of a rather large patch queue we seem to have outstanding at the
moment.
> The subtext here is that GIN, unlike the other index AMs, uses a
> representation that seems pretty amenable to supporting a wide variety
> of query types with a single index. contrib/intarray's "query_int"
> operators are not at all like the subset-inclusion-testing operators
> that the core opclass supports, and it's not very hard to think of
> additional cases that could be of interest to somebody (example: find
> all arrays that contain some/all entries within a given integer range).
> I think we're going to come up against similar situations over and over
> until we find a solution.
Interesting.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-01-19 18:48:12 | Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql |
Previous Message | Tom Lane | 2011-01-19 18:33:51 | Re: Extending opfamilies for GIN indexes |