From: | Andreas Karlsson <andreas(at)proxel(dot)se> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: GIN indexes on an = ANY(array) clause |
Date: | 2019-03-14 15:11:17 |
Message-ID: | d7c8e68c-32f8-0f76-7db0-de8d50791948@proxel.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 3/13/19 5:38 PM, Tom Lane wrote:
> regression=# select amopopr::regoperator from pg_amop where amopfamily = 2745;
> amopopr
> -----------------------
> &&(anyarray,anyarray)
> @>(anyarray,anyarray)
> <@(anyarray,anyarray)
> =(anyarray,anyarray)
> (4 rows)
>
> and none of those are obviously related to the =(int4,int4) operator that
> is in the ScalarArrayOp. The only way to get from point A to point B is
> to know very specifically that =(anyarray,anyarray) is related to any
> scalar-type btree equality operator, which is not the kind of thing the
> GIN AM ought to know either.
In the discussions for the patch for foreign keys from arrays[1] some
people proposed add a new operator, <<@(anyelement,anyarray), to avoid
having to construct left hand side arrays. Would that help here or does
it still have the same issues?
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Banck | 2019-03-14 15:26:20 | Re: Offline enabling/disabling of data checksums |
Previous Message | Amit Langote | 2019-03-14 15:06:34 | Re: [sqlsmith] Failed assertion at relnode.c |